A ZFS-t commit-olták a FreeBSD-be

FreeBSD

Pawel Jakub Dawidek ma bejelentette, hogy commit-olásra került a FreeBSD-be a Sun által kifejlesztett "Zettabyte Filesystem" (röviden ZFS). A ZFS egyelőre a HEAD ágban található, szélesebb körben a későbbiekben megjelenő FreeBSD 7.0-RELEASE-ben lesz elérhető, mint kísérleti funkció.

A FreeBSD-s ZFS az OpenSolaris-ból került portolásra a Sun mérnökeinek segítségével. A filerendszer a CDDL licenc alatt érhető el. A jelenlegi implementáció több limitációval is rendelkezik:

  • csak kernel modulként használható
  • csak i386-ra érhető el (amd64 a közeljövőben, más arch-ok támogatása később)
  • nem támogatja a róla való boot-olást
  • nincs iSCSI target daemon
  • nincs ACL és extended attributes támogatás

Ezek kivételével teljes a ZFS támogatás.

A bejelentés itt.

( bra | 2007. 04. 06., p – 09:16 )

Ezek alapvetően jó dolgok, a nagy kérdések azonban állnak: mennyire lesz megbízható, illetve mennyire fogják tudni követni az egyébként még a Solarisban is gyorsan változó ZFS-t.

Ha jól tudom a tru64-es (eredetileg vms-ből jövő) cluster (filerendszer) tudja ezt. Nekem nagyon tetszik a közös / a node-okon.

Egyébként totálisan "shared" filerendszert csinálni, hát...orrba-szájba lock-olgatni meg a többi...

Megmondom őszintén a ZFS-t nem ismerem, csak úgy általában a témával kapcsolatban:

A filerendszerek esetében utolsó szót mondani az nem mostanában lesz. Pl.:

-teljesítmény többnyire kisméretű v. többnyire nagy méretű file-ok esetén.

-Esetleg adott könyvtár-ban sok file állandó változásokkal, hozzáadás v. törlésekkel.
(directory file lock-olása, keresés a listában) stb.
gyalázatos teljesítmény lehet belőle

-Mekkora részét végzed a filerendszer adminisztrációnak a memóriában gyorsítás végett? Mennyi időnként szinkronizálsz? Mekkkora a buffer cache? Meddig tart az umount?
És ha crash van közben?

...akkor annyira bonyolult, hosszú idő alatt, és nehezen finomhangolható, hogy csak igen kevesen értenek hozzá valójában, és a kisebb képességű felhasználók végül - a szokásos módon - nem azt a következtetést vonják le, hogy nem értenek hozzá, hanem azt, hogy márpedig ez az fs egy sz*r. :)

init();

Az ellentmondás ott található a mondandódban, hogy a 'kisebb képességű felhasználók' nem hangolgatják a filerendszert és épp ezért nem is valószínű, hogy ők használnák speciális feladatokra, amelyekhez egy általános filerendszer (vagy ez a filerendszer a default beállításokkal) nem megfelelő. ;)

Azért a "kisebb képességű felhasználó" definíció alatt természetesen képzett informatikust kell érteni (csak nem fs témában), aki esetleg megkapta feladatul, hogy "akkor most javíts a teljesítményen 10%-ot, de ne nyúljunk az alkalmazásréteghez, mert az pénzbe kerül".

init();

Egy általános célú filerendszer sosem lesz annyira testreszabható hogy minden igénynek maradéktalanul megfeleljen.
Egy általános célú filerendszernek pont az a lényege hogy mindenféle igénynek próbál kielégítő módon megfelelni, ezért lehet maradéktalanul egyiknek sem fog.

Egyébként minél több komponensét lehet tuningolni, annál nagyobb az esélye hogy valahol be fog lépni a képbe az overhead.

Ráadásul sokszor a ratyin megírt -persze misson critical- alkalmazás lassúságán kellene javítani OS illeve FS tuninggal ami csak egy szintig lehetséges.

Szerintem ez a klasszikus "specialista" vs. "ezermester" filozófiai problémája.

Nagy becsben tartom a témában pl.:
Uresh Vahalia - Unix Internals: The New Frontiers
Ugyan jó pár éve kiadtak (készül a 2ik kiadás) de nagyon szemfelnyitogató tud lenni filerendszer témában is.

Cluster fájlrendszeren közös OS? Bizarr ötlet, legalábbis számomra. Bár lényegében az ftp.fsn.hu is ilyen volt jópár évig, csak a cluster FS-t NFS-nek hívták.

Mit jelent az a totálisan shared fájlrendszer? Lehet nem totálisan is?

Az egészet nem értem. Felvetettem, hogy a ZFS képes lehetne clusteres működésre is. Ez mindössze annyit takar, hogy a diszken lévő adatszerkezet támogatja a clusteres működést, az, hogy a fájlrendszernek ezt a képességét használod-e, vagy sem, rajtad múlik (-na).

Azaz ha nem clusteresen akarod használni, ugyanolyan gyors lehet, mint most, ha pedig clusteresen, akkor készülj fel a következményekre (mint ahogy azt nyilván most is teszed, ha cluster fs-t használsz valamilyen célra).

Hogy jön ide az, hogy mekkora buffer cache? A képességről volt szó, nem a megvalósításról.

-Mekkora részét végzed a filerendszer adminisztrációnak a memóriában gyorsítás végett? Mennyi időnként szinkronizálsz?

Áramkimaradaás ellen nem véd ugyan, de a S10 - mintha valahol olvastam volna - a memóriában is checksumozgat - ha meg nem jó cellát talál, azt egyszerűen nem használja. (ez is része a "Predictive Self Healing"-nek) - a ZFS-nek is központi része a folyamatos checksum-számolás.

a

Igen, és nem győzött meg a softupdates ...., de a ZFS-el is erölködnek, gondolom nem véletlenül.

Különben NetBSD hír:

http://digest.coris.org.uk/

Matt Fleming has started work on filesystem transactions for UFS on the mjf-ufs-trans-base branch. Branch provides a test journal but it's just a wrapper to bwrite and doesn't actually do any journaling.

Üdv
Godot