Fájlrendszerek, stabilitás, megbízhatóság

Linux-haladó

A téma megnyitására a következő dolog adott okot:
Egy driver betöltésétől kiakadt a rendszer, amely egyben a cég mailszervere is. Újraindítás után úgy tűnt minden működik, de kb. 5-10 perc elteltével szólt az egyik felhasználó, hogy teli van a postaládája nem neki címzett levelekkel.
A témafelvetés az lenne, hogy milyen fájlrendszert ajánlott használni abban az esetben, ha a rendszer folyamatosan és párhuzamosan több kis fájlal dolgozik, amelyek biztonsága a legfontosabb.
A fenti eset egy ext3 fáljrendszeren, kb. 60 mailbox postafiókkal, 10-20 levél/perc-es forgalom alatt történt, kb 5 mailboxba kerültek nem oda címzett levelek, átlinkelve más postafiókokból. Az fsck rendbehozta a fájrendszert, de jópár levél elveszett.
Tisztában vagyok vele, hogy a maildir egy jó megoldás ilyen problémára, de engem csak a stabil fájlrendszerrel kapcsolatos tapasztalatok, ötletek érdekelnének, elenyésző mértékben a sebesség, vagy más fájlrendszer-specifikus előnyök.

u.i. a rendszer virtuális gépként fut, 5-10 másikkal párhuzamosan, tehát hardware probléma kizárva, és a virtuális hdd image sem sérült.

  • 1057 megtekintés

( uid_1526 | 2007. 12. 20., cs – 18:15 )

Percenként 10-20 levél semmiképp nem okozhat gondot egyetlen normális filerendszernek sem. RAM környékén nézelődtél már?

( pinyo_villany | 2007. 12. 20., cs – 19:26 )

XFS:
-pro: "párhuzamos támogatása" a többi kiemeli a többi közül, gyors, jól managelhető, nagy fájlokhoz "optimalizálva"
-kontra: kis fileokkal lassabb mint a többi, érzékeny a "hard resetre"

more...

linux v2.6.22.14 + madwifi v0.9.3.3-mal itt
debian gnu/linux @ linux-2.6.22.15-pancs1

( gthomas | 2007. 12. 20., cs – 19:33 )

JFS (átlagban jól teljesít, megbízható, kicsi a CPU igénye), esetleg XFS (nem szereti, ha kirántják alóla a vasat (áram elmegy), különben gyors, kicsit több CPU-t eszik).
Reiser3-at én személy szerint nem javaslom, mert volt vele rossz tapasztalatom (kavar).
Reiser4 állítólag a leggyorsabb, legmagasabb CPU igénnyel, és legkacifántosabb licensszel.

A lényeg pont az, hogy a hardresetet bírja, és ne omoljon össze, és ha össze is omlik, a fsck gyorsan fusson le (ext-nél nagyon lassú, a reiser3 ilyen téren tűrhető). Az összeomlás másnapján áttettem Reiser3-ra, de amennyiben valaki tud javasolni valami stabilabbat, lehet, hogy váltanék.

JFS-t vagy XFS-t ha 

sync

opcióval csatolod, akkor a hardresetnél keletkező esetleges pufferelési veszteségeket kivédheted, és még így is valamivel gyorsabb fájlrendszert kapsz, mint az ext3, illetve nagy multimedia fileokra legalább egy nagyságrend a különbség xfs-nél, közepes méretű (pl.: mp3) fájloknál, illetve processzorhasználat szempontjából viszont a jfs viszi a prímet.
Egyébként az xfsnek van talán legjobb repair-kit-je az általam ismert fájlrendszerek közül, még egy látszólag teljesen "törött" fájlrendszert is helyre lehet ozni (xfs_repair).
Egyébként sync opció nélkül nem csak az xfs-nél, hanem a jfs-nél is van hardresetnél adatvesztésre lehetőség (bár kissebb), mert mindkét fájlrendszer nagymértékben kihasználja a hardver cache-elési képességeit, és ezéltal nyeri a kimagasló teljesítményét, ezért kritikus rendszereknél ajánlott a sync.
Egyébként hardresetnél nem omlik össze egyik sem (nem úgy, mint a reiser), hanem az utolsó néhány másodperc tranzakciói veszhetnek, ha éppen két commit között történik a hiba. Ebből a szempontból jobb a jfs, mert annak a naplózása nem metafájl alapú, hanem log alapú (ezért is a kisebb cpuigény), aminél kisebb a valószínűsége a hibás bejegyzéseknek, mint a metaadat-struktúra hibáinak xfs-nél.

üdv!
____________________________________________________________
Slackware 12/current - linux-2.6.23.9-olorin - KDE 3.5.8

>JFS-t vagy XFS-t ha sync opcióval csatolod, akkor a hardresetnél keletkező esetleges pufferelési veszteségeket kivédheted

szerintem sync-cel barumi lassu lesz, pont nagy erossege az XFS-nek a "delayed allocation"

talan a barrier/nobarrier opcio erre van. legalabbis a metadata tuti kikerul a diskre.