ZFS 0.8.0-rc1

Nagyon impresszív...viszont Matt Ahrens előadásából kiderül (fél óra után), hogy a device removal nem működik RAID-Z device-okra. Majd amikor landol a RAID-Z Expansion (amire szintén úgy vár mindenki, mint egy falat kenyérre), akkor majd ki lehet bővíteni a Device removalt, hogy működjön RAID-Z device-ra is, feltéve, hogy a pool összes többi device-a RAID-Z, ahol a width >= mint a törölni kívánt device width-je.

Részletek: https://www.youtube.com/watch?v=Njt82e_3qVo

Szerk: FYI a device removal során nem történik checksum ellenőrzés az olvasáskor (mivel teljesítményokok miatt alacsonyabb szinten olvas és nem nyalja végig az összes block pointert). A meglevő, javítható hibák ezután is javíthatók lesznek, mert pl. egy mirror-nak a 2 lábát, egy másik mirror 2 külön lábára fogja átmásolni, viszont a tranziens olvasási hibákat nem tudja detektálni, és szépen kiírja a másolt adatok közé. Ez (állításuk szerint) elég ritka, de fontos tudni, hogy ez a tradeoff létezik.

első meghajtón linux, másodikra telepítek freebsdt zfsel, semmi speckó. olvassa/írja a linux a második meghajtón lévő zfst?

Nos, írni akartam a ZFS-es kalandjaimról egy blogot, de végül is nem tettem, most leírom ide röviden.

--

Használunk FreeNAS-okat backup célokra, ZFS-sel. Jelen alanyunk egy 4 diszkes raidz2, wd purple diszkekkel, 16GB rammal. Az egyik ügyfélnél telt a kötet, szóltunk, hogy tele lesz, de nem jeleztek vissza semmit. Aztán megtelt teljesen. Akkor mondták, hogy OK, akkor rendeljük a nagyobb diszkeket és csináljuk a bővítést. Megjöttek, elsőre úgy gondoltam, hogy egyesével kicserélem nagyobbra őket, aztán mikor kész minden sync, megnövelem a kötetet, és kész. Remek ötlet volt, csak gyorsan megdőlni látszott, mert az első diszk csere után a resilver nagyjából 1,5MB/s-kel dolgozott. 1TB-ot így kiírni azért nem olyan vicces.... Gugliztam, kerestem, kérdeztem IRC-n, végül nagyjából az lett az eredmény, hogy:
1. "Miért WD purple? Biztos valami firmware-optimalizálás miatt ilyen lassú..."
2. "Teljesen megtelt a kötet? Jah, hát akkor azért lassú. Nem szabad hagyni megtelni."
3. "Sok apró fájl van rajta?" "Igen, mailbackup többet között, csillió fájl néhány K méretben." "Jah, akkor azért lassú."
4. "Igen, hát ez ennyi, de hagyd, majd ahogy megy előre begyorsul."
5. "Ez ennyi, hamarabb kellett volna elkezdeni a diszkek cseréjét." Könyörgöm, mennyivel hamarabb? Mert ezzel a tempóval hónapok alatt sikerült volna 4 diszket kicserélni.
Meg ehhez hasonló okosságok. Töröltem közben viszonylag "sokat", lett vagy 150GB hely, eldobtam szinte az összes snapshotot, és hagytam vagy 3 napig futni. És az eredmény? Semmi, ugyanilyen lassú, és sehol nem tartottunk 3 nap után sem (valami 18% talán, ha jól emlékszek). Próbáltam azt is, hogy tettem bele SSD-t, odaadtam neki előbb cache-nek, aztán lognak. Aztán tettem bele még egyet, lett cache és log is. Semmit jelentett, egy bit gyorsulást sem. Plusz mivel nem hotswap, ezekhez ki kellett kapcsolni a gépet, és indulásnál kezdi elölről a check-et az addig felírt adatokon, és miután ezeken végigmegy, majd csak utána kezdte a syncet tovább írni az új diszkre, szóval minden ilyen leállítással és indítással még órák mentek el. Közben az is előjött, hogy a régi diszkek 512 byte/sectorosak, és ezen ashift=9-cel lett (automatikusan) létrehozva a kötet, az új diszk meg már 4K szektorméretű, amire ashift=12 kellene, mert emiatt is lehet lassú.... Gugli következett. Az ashift értéket nem lehet változtatni vagy "upgradelni", az úgy marad, ahogy a tömböt megcsináltad. OK, ez kivárhatatlan.
Konklúzió:
1. Semmi köze a purple-nak ahhoz, hogy lassú (ez később derült ki).
2. Semmi köze a fullra telt kötetnek ahhoz, hogy lassú (ez is később derült ki). De egyébként ha így is van, akkor miért hagyja a ZFS teleírni a kötetet? Miért nincs reserved rész a root-nak, mint mondjuk ext-nél? Vagy miért nem veszi el "magának" azt a területet, amivel stabilan és gyorsan tud működni akkor is, ha a "user" számára látható terület tele van az utolsó bájtig? Ne is mutassa, akkor legyen az, hogy 1TB diszkből 800GB használható...
2,5. Anno pár ilyen FreeNAS-ba raktunk eleve SSD-t cache-nek, mert gondoltuk, hogy a sok kis apró fájlnál számít majd. Azok a FreeNAS-ok, amikben volt SSD cache, random időnként beálltak mint a beton, úgyhogy időközben lassacskán mindenhol kivettük a cachet, utána stabil lett. (Ez pár évvel ezelőtti FreeNAS verziókkal volt, nem tudom most mi a helyzet) A mentések, és egyébként semmilyen művelet nem változott utána, nem lett egy kicsivel se lassabb SSD nélkül.
3. Nem is az ashift miatt volt lassú.

Akkor B terv. 6 sata port van az alaplapon, 3 diszkkel elmegy a régi tömb, 3 diszkkel megcsinálom az újat, rsync, majd a régi ki, az újhoz hozzáadom a negyedik diszket, aztán kalap-kabát. Ez nem egészen 3 nap alatt le is ment... Majd adnám hozzá a negyedik diszket, nem akarja. Guglizok... Következő pofon: ezt sem lehet. A tömb az úgy van, ahogy a megkreáltad, azt semmilyen módon bővíteni, fejleszteni nem lehet. Nem lehet 3 diszkes raidz-ból sem 4 diszkes raidz-t csinálni, sem +1 diszk hozzáadásával raidz2-t, sem semmi mást. A stripe-hoz tudsz hozzáfűzni, meg a mirrorhoz diszket adni. Ennyi. OK, ez pebkac is, utána nézhettem volna mielőtt elkezdtem, de meg sem fordult a fejemben, hogy a nagy, szuper, mindenki által istenített zfs ezt nem tudja.

Úgyhogy, mivel már több mint egy hete nem ment a gép és nem készült mentés, úgy döntöttem, hogy nem kínlódok tovább, csinálok az új diszkekből egy új, üres tömböt, elindulnak rá a mentések újonnan nulláról, eltesszük a fiókba a régi diszkeket, várunk 2-3 hetet, addig nem csinálunk vele semmit (terv szerint bekerül majd másik gépbe), de reméljük hogy nem lesz rá szükség (nem volt).

--

Saját backup szervereken is ZFS lett kreálva, ez azonban centos és zfs on linux. Sima két diszkes ZFS mirror, semmi extra, a tömörítés volt bekapcsolva, illetve a snapshot volt használva. Fel van csatolva egy mountpointra, erre mennek a saját cuccainkról a mentések. Az egyik backupgépben haldoklott az egyik HDD, csere. Elindult a ZFS resilver. kb. 470K/s.... nem emlékszek pontosan mennyi volt, de nem volt 500K, ez tuti. Két 3T-s mezei toshiba desktop HDD, van egy 500MB-os boot, 20G a / a rendszernek, a többi a ZFS, tehát olyan 2,9T. Ebből 800GB volt foglalt. Ugyanolyanra lett cserélve a diszk, mint ami benne volt, tehát ugyanaz a szektorméret, és mindegy egyéb. 470K/s.... És nem, nem gyorsult jelentősen. Talán másnap már 540K-val hasított, és akkorra talán 2-3%-on állt a resilver, vagy valami ilyesmi...
Ez volt az a pont, amikor eldöntöttem, hogy kivágom a ZFS-t, mint a macskát ...... .
Csináltam az új diszken lévő partícióra egy féllábú mdadm raid1-et. Majd indítottam egy rsync-et, aztán ha ez kész, akkor yum remove zfs*, a partíciót meg hozzáadom az md-hez. Ennek az rsyncnek 1 nap alatt 200GB-nyi (mondjuk hardlinkelt, tehát valójában több...) adatot sikerült átmásolnia. Nem számoltam ki, hogy az hány K/s, mindenesetre ez is lassú, resilver és mindegy egyéb nélkül is. Itt az lett, hogy a zfst meghagytam, lecsatoltam, a féllábú md-re mentek (pontosabban indultak újra ide is, nulláról) a mentések innentől, majd egy hét után hozzácsaptam a zfs-es partíciót az md-hez. Az md 170-180MB/s-kel syncelt, valami 4 óra alatt leszinkronizálta a nem egészen 3T....
A másik backup szerver is "vissza" lesz csinálva sima md raidre hamarosan.

--

Van pár jó funkciója a zfs-nek, mint pl. a tömörítés, a fájlrendszer szintű deduplikáció (ezt nem használtam), valamint az, hogy a snapshotokat tök másképp kezeli, mint az LVM, és kb. lehet akárhány, nem lassul tőle jelentősen (az LVM-nél érződik a sebességén már 3-4 snapshot is, 10-15-nél meg brutálisan), tök jó a kvótakezelése, ezeken a területek rugalmas. De amit én tapasztaltam ez a brutális lassúság a resilvernél, és a nem ép tömbnél, valamint az a "rugalmatlanság", hogy a tömb az úgy van ahogy megkreáltad, és nem lehet sehogy sem átalakítani, konvertálni, ez nekem teljes csalódás. Mdadm-nál bármikor hozzácsapsz egy diszket a kötethez, vagy akár elveszel (mondjuk raid1-ből)... Vagy on-the-fly csinálsz egy raid5-ből raid6-ot. Ezeket ZFS-nél felejtsd el. Lehet erre mondani, hogy ez "enterprise", és itt nem foglalkoznak azzal tömböt bővítsenek vagy diszkeket cseréljenek, hanem vesznek egy komplett új storage-ot új diszkekkel, ezért nincs benne, mindenesetre ez KKV-nál nagyon gyakori, így emiatt oda teljesen alkalmatlan. És persze az eszméletlen csiga lassú resilvert meg olvasást nem magyarázza meg.

Úgyhogy jelen állás szerint, nekem a véleményem a ZFS-ről: Nagyban* lehet, hogy jó, solarison lehet, hogy jó, de kicsibe nem, és KKV-ba nem is való a leírtak miatt, úgyhogy látni se akarom többet. Egy mdadm+lvm+ext4 százszor rugalmasabb, gyorsabb és stabilabb.

Nagy:
- Akik nem azt csinálják, hogy vesznek pc-t vagy akár egy kis szervert, és elkezdenek bele +1 diszkeket pakolni mindig, ha fogy a hely.
- Vagy egy 24 diszkes storage-ot, és tesznek bele 8 diszket, aztán bővítik 16-ra, majd 24... Hanem megveszik rögtön 24 diszkkel.
- Vagy aki nem diszket cserélget, hanem ha megtelik, vesz kompletten újat, storage-ostól, mindenestől.

--
"Sose a gép a hülye."

zfs csak egész meghajtóra mehet vagy partícióra is lehet tenni?