Elindultak a "ZFS on Linux" levelezési listák

Címkék

Mint az ismert (1, 2) a KQ Infotech / KQ Stor nemrég elérhetővé tette a "ZFS on Linux" bináris csomagjait és a forráskódokat is. A cég most bejelentette, hogy elindultak a levelezési listák is.

  • kqstor-zfs-announce - A "ZFS on Linux"-szal kapcsolatos bejelentések levelezési listája. Erre feliratkozva lehet értesülni pl. az új kiadásokról.
  • kqstor-zfs-discuss - A termék használhatóságával, funkcionalitásával kapcsolatos levelezési lista.
  • kqstor-zfs-dev - Fejlesztőknek szóló lista.

A listákon jelen vannak a KQ Stor Support Team tagjai.

Hozzászólások

Sok sok beszélgetés volt már a ZFS-ről, de mi az a kb X indok a használatára annak aki használja? Szétválasztható-e a solaris*-zfs páros?

Annak, aki helyi fájlrendszerként akarja használni, miért lenne fontos a target mód? Annak meg, akinek fontos, használhatja az adott OS-ben lévőt (Linuxhoz is van ilyen).
Ennyi erővel azt is mondhattad volna, hogy nem, mert NFS szerver csak a Solarisban van.

suckIT szopás minden nap! Mi lesz az utolsó 2000 magánnyugdíjpénztár-taggal?

Tulajdonképpen igazad van, attól eltekintve, hogy a ZFS alapú megoldásokat épp a target funkciót kiemelve árulják. Linuxos targetből meg szokás szerint van többféle, az egyik jó ebben, a másikat integrálták a kernelbe, a harmadikat meg valamelyik Enterprise Linux gyártó támogatja.

Könnyű kezelhetősé, dedup, checksum, tömörítés, többféle adatbiztonsági szint, prefetch, l2arc, külön, állítható log device(ok), dinamikusság (módosításokban, beállításokban), viszonylag jó teljesítmény stb.

suckIT szopás minden nap! Mi lesz az utolsó 2000 magánnyugdíjpénztár-taggal?

Tudom, hogy azt írod, "viszonylag", de gyakorlatilag azért mindenhez képest lassú tud lenni, még ez az új, kernel módú driver is.
A könnyű kezelhetőségért nem ájulok be, nekem az eddigi megoldások is könnyen kezelhetőek, dedup nem tudom, milyen szinten működik ebben a driverben, de majd meglátjuk.
Összességében nem értem ezt a ZFS hype-ot, egy rohadt nagy ígéretlufi volt, ami amint dolgozni kellett volna vele, kidurrant, és kiderült, hogy sok szempontból trágya, és van, ahol még a jó öreg UFS is megveri.

Nem tudom, hogy csak a Linuxos zfs-ről beszélsz, vagy a zfs-ről általában.

(open)Solarissal csináltam egy rsync mentő szervert 4-5 linux napi mentésére.

FS tömörítés és dedup, elég sok helyet spórol (dedup kb 21%-ot, a tömörítésen felül)
A checksum elég jó biztosíték, hogy a mentett adatokról ne a visszatöltéskor derüljön ki, hogy bithiba miatt kuka.
Mentések után automatikus snapshot, így veszett egyszerűen lehet a korábbi mentéseket elérni, és nevetségesen egyszerű a mentések rotálása.

File rendszerek adminisztrációs feladatai egyenként delegálhatók usereknek, szükség esetén fél perc alatt bővíthető, stb

Könnyű kezelhetőség: 1-2 óra alatt összeraktam az egészet, halál egyszerű scriptek, kevés hibalehetőség.

Sebesség: backup szervernél kb. lényegtelen.

En zfs-fuse-t hasznalok linux alatt es a checksum az ami miatt hasznalom. Elotte tobbszor volt 4 diszkes raid5 tombon bithibam (a hibas es az eredeti file kozott egyetlen bit kulonbseg van), meguntam, es atcsinaltam zfs-re. Szamomra nagyon jo, ha valahol hibat eszlel, automatikusan kijavitja a redundans adatokbol. Ha pedig tobb diszken is hibas ugyanaz a resz, akkor a zpool status -v parancs szepen kiirja mely fileok a serultek, es ha olvasni probalod azt a filet, akkor IO errort dob a hibas reszen (kiprobaltam). Igaz teljesitmenybol buktam valamennyit, de megerte, mert a silent data corruption nalam nagy mumus.

Nem mondom, hogy gyakran van, de nálunk csak kevés diszk pörög, ahol több van, ott az esélye is nagyobb. Rejtett (rejtve maradt) adatkorrupció miatt vesztettünk már adatot hardveres RAID vezérlővel, nem is egyszer.

Pld:

NAME STATE READ WRITE CKSUM
label/disk20-05 ONLINE 0 0 4
label/disk21-07 ONLINE 0 0 1