Helyzetjelentés a ZFS on Linuxról

Fájlrendszer, NAS, storage

A ZFS on Linux (röviden "ZoL") itt van már körülöttünk egy ideje. A HUP-on számtalanszor volt róla szó. Brian Behlendorf 2010-ben jelentette be, hogy Linuxra ZFS támogatáson dolgozik. 2013 tavaszán pedig azt, hogy kész a széleskörű használatra.

De mi a helyzet vele most, 2014. őszén? Richard Yao a ZoL projekt második legtermékenyebb hozzájárulója. Munkája során főként a runtime stabilitásra, a POSIX-megfelelőségre és a kernel/userland kompatibilitásra fókuszál.

Richard szerint a ZoL kész az éles környezetben való felhasználásra. Írása elolvasható itt.

( _ventura_ v | 2014. 09. 14., v – 17:14 )

Remélem is hogy kész. Ugyanis gondolva egy merészet, ideiglenes(1-3hónap) samba4 szerver alá tettem ZFS-st. 10db 1T-s disk és 10db 3T-s disk-re. Előzetes tesztek szerint jobban teljesített mint a mdadm + lvm + ext4. Viszont ette rendesen a ramot (16G) és a cpu-t (i3).

Fedora 20, Thinkpad x220

Ha dobozos, akkor gondolom csak ECC..

Mindenesetre pl.:

http://blog.brianmoses.net/2014/03/why-i-chose-non-ecc-ram-for-my-freen…

"Even more so for any ZFS filesystem like FreeNAS uses, bad RAM in ZFS could potentially do more than just corrupt a file or two, it could — and has — render the pool unmountable."

Erdesem szem elott tartani mindeneskelott.
Nem fontoskodasnak szantan, hanem mert i3-mal viszonylag ritkant latni ECC-s setupot:)

t

Kezdetben volt az mdadm + lvm + ext4. Ezt úgy szerveztem, hogy az első 10 disk (1T WD black caviar) 1 raid6 majd raid10, a második 10 lemez (3T WD red) szintén, majd LVM és ext4-ra. Így a kapacitás raid6-nál kb 28T, raid10-nél olyan 18T lett. Csináltam bonnie++ meg dd teszteket. Az 1T-s black caviar gyorsabb volt mint a 3T red.
dd értékek:

raid6 nél az 1T-s lemezeknél: 209MB/sec az 3T-s 183MB/sec. Raid10 nél az 1T-s 570 a 3T-s 330.

Nahh most jelenleg ZFS nél 2 db raiz2 van külön az 1T és külön a 3T-s lemezekből, és ez a kettő van egy poolban. Nahh most egy sima dd nél olyan 800MB/sec feletti érték jött ki.

Ugye ezek elég felületes tesztek de jól mutatja hogy a zfs jól stripeolja az poolban levő raidz-ket. Annak ellenére hogy nem egyformák voltak a raidz poolok. A synology-nak van egy hibrid raid megoldása, ami hasonló. Ugyanis jelen felállásban a 3T-s diskekből particionál 1T-s részeket, így 22 lemezből lesz 1 mdadm tömb a maradék 2T-sekből meg még1 és ezekre jön az LVM+ext4.

Ezt kézzel nem volt kedvem megcsinálni. Meglátjuk mire lesz elég ez a zfs-s ezzel a hw-el.

Fedora 20, Thinkpad x220

( Ritter | 2014. 09. 15., h – 00:40 )

A másik hasonló projekt, a BtrFs hogyan áll?

A Btrfs a RAID szintekből tudtommal egyenlőre csak a 10-et kezeli, az egyéb feature-ökben nagyjából megegyezik ZFS-sel (van ami az egyikben egyszerűbb és elegánsabb, van ami a másikban). Stabilnak elég stabil mind a kettő (a Btrfs-en a Facebook csinált stressz-teszteket, mióta Chris Mason náluk dolgozik, ez a default linuxos fájlrendszerük). Ami fontos különbség, hogy a ZFS hordozható (Solaris, BSD és Linux között), viszont a licence nem kompatibilis a GPLv2-vel, így sosem lesz a vanilla kernel része.

> így sosem lesz a vanilla kernel része.

AFAIK igazabol Linus nem zarkozna el tole.

A btrfs-sel kapcsolatban a laptopomon azt tapasztalom, hogy minden egyes alkalommal, amikor snapshot keszul v. torlodik, hogy megall az elet par masodpercre. Aztan rendben visszajon ujra, de ...

> ez a default linuxos fájlrendszerük

Most nem talalom a cikket (pedig talan pont itt olvastam a hupon), de mintha az ellenkezojere emlekeznek. Tudsz adni vmi tampontot?

Lehet, hogy rosszul emlékeztem. Itt egy cikk, idén júniusból: Smooth like btrfs
Eben azt írja: “Very soon after I joined, they had a selection of machines carved out to run btrfs.” Meg a cikk végén: "Mason contacted Network World after this story was published to clarify that the entirety of Facebook’s infrastructure isn’t slated for a move to btrfs."
Szóval használnak, de nem mindenhol, nem defaultként. Vagy nem tudom, de az biztos ;)

Valójában a btrfsben kb minden online van, van egy offline btrfsck, de a mount is tud jópár hibát kezelni, és amit nem, akkor is van esély, hogy read-only ra visszavált. Filerendszer sélrülés esetén (winyó, ram miatt) amit lehetett menteni, azt többnyire a readonly mounttal sikerült, de volt hogy btrfs fi recovery kellett. Az fsckt csak érdekességként próbáltam, és valóban többet ártott, mint használt (ez minimum 1 éve volt), de ezen kívül sosem hiányzott.

A torrent partícióm Btrfs rendszerű, Linux Mint 17 alatt használom. A sebessége elég korrektül ott van és többször ment el alatta az áram is, semmi baj nem lett. (bár ez tán betudható a torrent természetének is)
Viszont azt olvastam, hogy Btrfs-t problémás törölni, ha betelik. Ez nálam nem igazán fog megtörténni, de azért remélem nem tapasztalom első kézből.
Még itt HUP-on ajánlotta valaki torrentezéshez, gondoltam miért ne... eddig jó.

Linux Mint 17 Cinnamon 64-bit

Hát igen, a copy on write miatt hajlamos a töredezésre, ha tele van a winyó, akkor teljesen elkezd szanaszét fragmattálódni. Ez egyébként mondjuk más filerendszereknél is így van, itt a cow miatt durvábban. Erre az én megoldásom az, hogy ha felszabadítottam elég helyet, akkor defragolok, a metadatat, és a nagyon töredezett fileokat, két egyszerű scripttel.

Hogy ne a levegőbe beszéljek, itt letölthető két php és egy include hozzá. Igen, phpban van a defragoló script... :D

http://dblaci.hu/btrfs_defrag_php_20140915.zip

Lehet a zfs on linuxot máson használni rootfs-nek?
Linux finestra 3.13.0-35-generic #62-Ubuntu SMP Fri Aug 15 01:58:42 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.1 LTS"

Mondjuk azért fagy is, feltételezem a swap miatt...

FreeBSD-n azért kiforrottabb, csak sajnos az ezen a notebookon használhatatlan (az ubuntu is épp csak átlépi a szintet). :)
--
zsebHUP-ot használok!