zfs helyett milyen fájlrendszert?

Naplózó filerendszerek (journaling)

Sziasztok!

Eddig zfs-t használtam, de sajnos az egyik gépemen sikerült egy vissza-visszatérő problémába belefutnom, abban meg nem nagyon bízom, hogy a fejlesztők épeszű időn belül kijavítanák.

Szóval keresek egy fájlrendszert zfs helyett.
Ami miatt eddig zfs volt:
- minden adat checksumolva, scrub esetén helyreállítja a replikákból
- nem kell bajlódni a raid-lvm-fs vonalon, egyben minden, átlátható
- ssd mint cache
- lz4 tömörítés

Talán a btrfs áll még ehhez legközelebb, de az nem annyira tetszik (lz4 helyett lzo, ssd cache nincs, nem annyira átlátható mint zfs) meg a fejlődését sem látom.

Szóval ha valakinek van valami ötlete, kérem ossza meg! (centos7-hez kell)
Köszi
S

  • 3816 megtekintés

( uzsolt v | 2015. 01. 03., szo – 10:44 )

Nem tudom, mi az a vissza-visszatérő probléma, de nem lehetséges, hogy pebkac? Ha pedig valóban bug, a fejlesztők tudnak róla?

Lehet, hogy pebkac :)

Bejelentettem nekik a githubon, kapott egy bug-minor jelzőt.

Röviden: két hdd, mirrorban, néha ssd cache-sel néha nem, rajta lxc containerek, messagesben semmi érdekes, kb hetente megjelenik egy txg_sync D státuszban, innentől nem tudok rebootolni se containert, se hostot, a D processzek darabszáma néha nő, aztán pár nap után megáll a gép. Gép távol, resetet ezért csak segítséggel tudok nyomni meg igazából nem is szeretnék resetet nyomni :)

Szia,

Gondolom erről a ticketről van szó:
https://github.com/zfsonlinux/zfs/issues/2978

Szerintem teljesen korrekten foglalkozik Brian a problémával, karácsony és újév között logikus, hogy pihennek, előtte írt ötletet, hogy mit próbálj csinálni, ami sajnos nem jött be. Azzal tudnál neki segíteni a hibakeresésben, hogy az spl-t --enable-debug kapcsolóval fordítod (úgy látom az rpm specfilenak van ilyen opciója), mert akkor talán a dmesg-ből és a stacktrace-ből több minden ki fog derülni.

A legnagyobb gond ezzel a hibával fejlesztői szempontból, hogy a reprodukciós ideje ~1 hét. Ezt kellene megpróbálni csökkenteni valahogy.

Emiatt én nem keresnék más FS-t zfs helyett.

Üdv,
Gergely

Igen, arról van szó. Igazából én sem szeretném lecserélni, csak ahogy elnéztem nincs túl sok fejlesztő és ahogy mondtad, időbe kerül reprodukálni. Így szerintem el fog húzodni az egész, ezért gondoltam, hogy körbekérdezek, mi van még a "piacon", ami esetleg elkerülte a figyelmemet.
Azon is csodálkozom, hogy csak nálam jött elő, ezért úgy érzem benne van tényleg valami pebkac vagy eldugott hw hiba, ami sose derül ki :/

( sibike | 2015. 01. 03., szo – 18:28 )

Jól összefoglaltad, pontosan ilyet szeretnék én is Linuxon lassan már egy évtizede. :(

És nagyon jól írtad, a btrfs áll ehhez a legközelebb, szégyen, hogy idestova 7 év alatt sem tudott olyan stabil lenni, hogy bátran merjem prod. környezetben használni.

( dblaci | 2015. 01. 04., v – 09:09 )

btrfs:
checksum defaultból
scrub helyreállítja a replikából a sérült adatot, a metadata default duplán van, az adat duplikálásához raid1 mód kell két eszközzel (de egy fs, és filerendszer kezel mindent)
tömörítés (lzo, zlib)
ssd cache filerendszer szinten nincs, de a bcache egy + réteg a filerendszer alatt máris megoldotta.
"meg a fejlődését sem látom" - Fejlődik szerintem, mit hiányolsz?

Egy ideje igérgetik a raid5-6, ssd cache implementaciókat, az lz4-gyel sem jutottak előrébb, kb ezeket hiányolom (mondjuk az lzo-val még pont kibékülnék). Éppen lehetne bcache, flashcache vagy dm-cache, de akkor ugyanúgy nem úszom meg a plusz réteget, több ssd kell hozzá (lemezenként egy), meg nem is lenne olyan jó a találati arány (pl pont a másik lemezről olvassa az egyiken már cache-elt adatot).

( hory v | 2015. 01. 04., v – 15:48 )

En kb 3-4 evvel ezelott, mikor eloszor osszeraktam a raid5 tombot otthon, szinten szemezgettem, hogy milyen lenne a zfs/btrfs, de vegul a kiforratlansaga (= kod bonyolultsag + alacsony hasznalat rata elesben) miatt sima ext4-re tettem le a voksom.

Most, sok evvel kesobb a fejem fogom, hogy meg mindig pontosan ugyanez a helyzet. zfs/btrfs kiforratlan, nem hasznalt, ext4 egyeduli tenyleg megbizhato FS.

Amugy SSD-n sebesseg szempontjabol tokmindegy, milyen FS-t hasznalsz, mert ugyis a 600MB/s ATA port a limit mai SSD-ken. Az extra feature-ok meg nem erik meg a megbizhatatlansagot, tokolodest:

- kulonallo backup sokkal jobb barmilyen checkpoint/replika feature-nel;
- grow/shrink tokeletesen tamogatott (online is tobbnyire, bar itt-ott van limitje) mind md, mind ext4 szinten;
- SSD cache van kulon is, nemcsak ssd reszekent;
- tomorites SSD mellett nemigen szamit, de megoldhato szinten.

> zfs/btrfs kiforratlan, nem hasznalt, ext4 egyeduli tenyleg megbizhato FS.

Onmagaban ez igy nem igaz. A zfs/btrfs olyan feature-oket tud, amiket az ext4 sosem fog. Amennyiben az adatintegritas fontosabb mindenek felett, akkor valoszinuleg a ZoL lekorozi az ext4-et (a btrfs-rol nem tudok nyilatkozni). Innentol a megbizhatosag csak csak definicio kerdese.
Tovabba ha megfelelo HW-t kap a ZFS maga ala (leginkabb elegseges mennyisegu ECC RAM) es/vagy hozzaerto kezeket, akkor a sok (legtobb?) esetben a rajta futo szolgaltatas megbizhatosagaval is pariban van (esetleg nyeresre is all, megint csak nezopont kerdese).
Sebessegben valoszinuleg sajnos sosem fog nyerni az ext4-gyel szemben.