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

 ( trey | 2011. február 1., kedd - 8:54 )

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ás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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?

Szerintem nehezen. A COMSTAR is elég fontos a zfs fölé/köré, azt pedig nem portolták a többi rendszerbe.

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.

Miért éppen a lényeges dolgokat hagyod ki? Én inkább ezekre gondolnék: volume manager, copy on write, snapshot.
--
CCC3

Mert ezek alacsony buzz word pontot kaptak. :)


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Egyfelől nem gondolkoztam percekig, másfelől pedig ezek egy része szinte mindenhol máshol megvan már, ill. a felsorolt listában belefér a könnyű használat kategóriába.


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

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.

Ebbe milyen gyakran futsz? Vagy ez a karmad? :D Nekem meg nem siekrult hasonlot produkalnom /kopp-kopp-kopp/, se soft, se "hard" raid megvalositasnal.

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

Checksumot számolni a btrfs is tud.

Amint stabilnak nyilvánítják, adok a btrfs-nek egy esélyt. A ZFS-sel azért nem szimpatizálok, mert azt mondják róla, hogy túl sok RAM-ot igényel (GB-okat).

ohhh, varj, btrfs-t mirol is masoltak? hmmmm, csak nem a ZFS-rol?!
___
info

ohh, Arra gondolsz hogy a tervezekor mar ZFS hibait is figyelmbe vehettek ?

Mi hozzaszolasod ertelme ? Mert ez enyimenk sincs.


Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Az 1 GB feletti memoriareszt hasznalja az ARC cache-nek, de ennek a meretet egy kernel parameterrel lehet limitalni.

A btrfs nem tud raid5-ot. Lehet alá tenni raid5-ot, de ezzel nem fogja tudni megjavitani a checksum error-okat.

A zfs-fuse most nekem 250MB RAM-ot eszik egy aktiv hasznalatban lévő 7TB RAIDZ pool-on.

Azt javaslom, hogy az "azt mondják róla" helyett sajat tapasztalatok alapjan dönts.

Én azért nem nézném elégedetten hátradőlve, hogy a ZFS ismeretlen eredetű bithibákat javítgat a szerveren.. :)

A főmemória biztos vétlen..?