reiserfs vs ext4?

Linux-haladó

Sziasztok!

Van egy szerverem, ahol folyamatosan 50 Mbit/sec forgalom van (webkamerák), nagyon sok lemez írási/olvasási művelettel. Jelenleg éppen egy CentOS 5.6 döglött be rajta ext3 fájlrendszerrel. Úgy néz ki újra telepítem. Az oprendszer valószínűleg Slackware lesz. A fájlrendszeren nagyon gondolkodom a reiserfs-ben, mivel rengeteg kis fájlt szolgálok ki úgy érzem sokkal jobb választás mint a jelenlegi ext3, viszont évekkel ezelőtt nagyon megszívtam egy éles szerveren a reisert egy áramszünet után, gyakorlatilag teljes adatvesztés történt, azóta úgy tudom a fejlesztő is börtönben ül...
Szóval ti bevállalnátok egy éles nagy forgalmú rendszeren reisert vagy inkább azt ext4-et választanátok?

Köszönök minden javaslatot.

  • 5485 megtekintés

( MGy v | 2011. 05. 02., h – 20:11 )

Bár nekem nem volt vele adatvesztésem, de nem vállalnám be.

:D Én is JFS használó vagyok, mióta kijött az első IBM-es kernel patch, abban még "javítottam" is egy problémát. :D

Szvsz azért annyira nem egy sebességbajnok (hajlamos cpu-t enni), ahogy a tesztekben látszik, de borzasztó megbízható, és nem csökken a teljesítménye huzamosabb (évek) használat után sem "nagy" méretű (1T+) kisfájlos köteteken.

A jóságát magyarázni nem nagyon lehet, hiszen az emberek többsége ritkán mer új dolgokat élesben kipróbálni (helyes! :D ), én is csak a 10+(!) éves pozitív tapasztalat okán merem produkciós környezetben használni.

Elhiszem, hogy valakinek ugyanez a pozitív tapasztalata megvan ReiserFS-ből, vagy XFS-ből. (Nálam anno mindkettő adatvesztett a "fájlrendszer stressztesztemen", bizalmam megrendült egy életre bennük, és nem érdekel, hogy lehet hogy a hw volt fura alattuk, ha ugyanazon eszköz ext3/jfs alatt ugyanúgy nem bukott adatot.)

Stb.

Ha vki amúgy Reiser3 vs. Ext4 kérdést tenne fel, gondolkodás nélkül ext4 lenne a válaszom. ;) Meg sem említeném a JFS-t. Nem értené... :D :D

( Lacyc3 v | 2011. 05. 02., h – 20:34 )

Ext4. Volt már kisebb - nagyobb adatvesztésem reiser-el és ext3-al is, de a 4-es eddig mindent bírt.

( calamari | 2011. 05. 02., h – 20:58 )

"nagyon megszívtam egy éles szerveren a reisert egy áramszünet után, gyakorlatilag teljes adatvesztés történt"
reiser-el már én is jártam hasonlóan.
Nem tartom megbízható fájlrendszernek, éppen emiatt nálam nem opció.
xfs-ről úgy tudom, hogy elég jó a teljesítménye, nem volt vele még adatvesztésem.
"xfs vs ext4"-re érdemes egyet googlizni. Elég jól teljesít az ext4 is.

( STP | 2011. 05. 02., h – 21:04 )

Halkan jegyzem meg, hogy a CentOS 5.6 már kezeli az ext4-et.
Csak telepíteni kell az e4fsprog csomagot.

Ja, és a kérdésedre. Reisert én soha. (Gyilkos egy rendszer ;)

Oreg Gentoo-skent nagyon faj, hogy ezt kell mondanom, de a mostani Gentoo-t nem biztos, hogy ajanlom szerverre. Mondjuk az Arch ennek a masik fele, ugyhogy inkabb openSuSE, vagy Debian. Az elobbi az enterprise szintu QA miatt jo, az utobbi pedig akkor, ha valaki fel a nagy gyartoktol.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Sorozatgyártás, tehát TÖBBEN mások is használja hasonló célokra, körülmények között, kiszámítható és nem egyéni, más ország Bob csimpánz által is elvégezhető, életben tartható, karbantartható, átlátható, megjósolható, nem kivágással helyrepofozható, tehát életre kelthető és ilyenkor nem idézi a magyar narancsot vagy a zombit.
--
Solaris Express, Opera, OpenOffice.org, Yebol

Oreg Gentoo-skent nagyon faj, hogy ezt kell mondanom, de a mostani Gentoo-t nem biztos, hogy ajanlom szerverre.

én nem szerverre nem ajánlanám, hanem gentoo-kezdőnek éles gépre.

kell hozzá egy infrastruktúra (chroot-ban binhost, 20-30-40GB diszkterülettel, optimális esetben egy nem éles gépen) és rendes change management policy (nem rakosgatunk/állítgatunk minden szart össze vissza, nem akarunk "tegnapra" új package-eket a gépre), és úgy akkor kezelhető.

egy gépen, élesben, totális oboa.

Binhost nem feltetlen kell, foleg, ha eltero procikkal vannak a szerverek. A szerver szoftverek hamar fordulnak, KDE meg OOo ugyse fog kelleni, a tobbi meg tenyleg kivarhato kategoria.

A change management-tel egyetertek, de az igazabol disztrofuggetlen.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

A binhost azért kell (és azért nem kell rendes distroknál), mert gentoo-ból nincs két egyforma. Ha az egyik gépemen reggel rsync-elek, a másikon délután (esetleg nem is pont ugyanarról az rsync mirrorról), a halál egyforma verziójú package-ek sem biztos, hogy ugyanúgy fordulnak, mivel embereink néha fixálják a szar ebuildeket verziószám váltás nélkül.
Innentől kezdve a change management kezelhetetlen: pl. egy nem forduló package esetén nem tudsz rollbackelni az előző, még működő verzióra, ha időközben
a) már az sem fordul (pl. a dependens package-et megfrissítették inkompatibilis módon)
b) azt már kivették az rsync fából
Ergó fordítani ott fordítunk, ahol nincs éles használat, mert simán belenavigálhatjuk magunkat egy olyan csőbe, amiből nincs kiút semerre. Én pl. úgy csinálok egy nagyobb frissítést, hogy naponta egy rsync snapshot egy héten keresztül, mert rendszeresen nem fordul a legfrissebb rsync tartalomból simogatás nélkül az egész rendszer. Ilyenkor kikeresem, hogy mit szartak el, és visszamegyek az azt megelőző napi rsyncre.

Oke, de heterogen szerverparknal egyszeruen nem eri meg annyi binhostot tartani. En inkabb a GLSA nyuglodesmentessegere hajtok, vagyis ha valami kijon GLSA-ban, azt lefrissitem es csa. Mukodo rendszert nem piszkalunk.

Emiatt meg mindig van olyan rendszer, ahol a 5.2.14-es PHP van fenn, mert a 5.2.17-es mar masik slot meg tok masutt keresi az iniket. Amire az ott hasznalva van, arra bosegesen eleg.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Elmondom én, hogy mi ezzel a probléma. Én is így csináltam egy darabig.

Csakhogy nem tudod összemerge-ölni az eredeti rsync-fát a frissítésekkel.

Azaz addig tudod csinálni ezt a játékot, amíg egy új package vagy use-flag igény, vagy glsa frissítés miatt valamelyik régi package-et meg nem kell bolygatnod, és lyukra nem futsz (= a már fent levő régi package-et nem tudod újrafordítani, mert az új rsync fában már nincs benne, vagy az ott levő ebuilddel már nem fordul).

Az elv nagyon jó lenne, csak azt kéne elérni, hogy az éppen fent levő package-ekhez tartozó ebuildet a rendszer tárolja el külön, hogy az rsync ne tudja letúrni.

( psc | 2011. 05. 02., h – 21:22 )

"viszont évekkel ezelőtt nagyon megszívtam egy éles szerveren a reisert egy áramszünet után, gyakorlatilag teljes adatvesztés történt,"

már kiskorában megtanulja az ember, hogy sárkány ellen sárkányfű, tehát áramszünet ellen szünetmentes...
(márha fontosak azok az adatok, de akkor meg azt is érdemes tudni, hogy a fenti analógiának megfelelően, adatvesztés ellen backup...)

Akkor, ha van szünetmentes végül nem is kell journal, úgyis csak rontja a teljesítményt. :)
Egyébként a szünetmentes az egyféle eszköz arra, hogy áramszünet esetén megvédjen az adatvesztéstől.
A fájlrendszer naplózás meg egy másik. És mindkettő jó, ha van.
Viszont ha nincs szünetmentes, akkor is szeretném, ha a fájlrendszerem megvédene az adatvesztéstől amennyire csak tud.
Mert ugye szünetmentes az egyszerűen nem mindig van, és az adatok ettől függetlenül lehetnek fontosak.

Ez így szerintem túlzottan egyszerű megfogalmazás. Ha jól emlékszem a journal arra való, hogy mindig legyen egy konzisztens állapota az fs-nek, azaz fel lehessen mountolni akkor is, ha kernel picnick vagy áramszünet áll elő. Az, hogy a journal-ban benne van-e minden olyan dolog ami az adatvesztés elkerüléséhez kell már csak szerencse kérdése.

Full data journal - ha van, akkor az ADAT integritás sem gond. A linuxos fs-ek metadata journalingot csinálnak alapból (nem tudom valamelyiket rá lehet-e bírni full datá-ra), így fs integritásra számíthat csak az ember.
Gyors fsck, hogy hamar lehessen dönteni a backup vissztöltésről. :D

Ez is kérdéses szerintem hogy hogyan működik egy db fájlai esetén, ahol adatintegritást az fs nem tud biztosítani, hiszen az adattömbök kár több, különálló fs-en is lehetnek szétszórva. De ha eggyen is van... honnét tudná az fs, hogy az adott fájl úgy jó-e ahogy van.

Gondolom ezért (is) szeretik inkább a direct io-t vagy a raw eszközök használatát.

Alkalmazástól függően egész jól védhet. Pl. news vagy smtp szerver esetén, azaz ahol az "igazi" adatok az fs által egyben kezelt egységekben vannak, azaz fájlokban (ez hülye megfogalmazás, de gondolom érthető mire gondolok).

Viszont egy DB esetén, ahol az "igazi" adatok el vannak rejtve egy vagy több, állandóan nyitott fájl belsejébe, ott szerintem a journal se segít. Viszont a DB-knek - talán épp ezért - van saját logja, journal-ja vagy egyéb védelme, és elég neki annyi, ha az fs mountolható mondjuk egy heveny áramszünet után. Amiben megint csak segít a journal.

De ahogy mondani szokták, halál ellen nincs orvosság.

Szar az a szunetmentes, aminek domboru az oldala... :-)

Kicsit komolyabbra veve: egy jol karbantartott szunetmentessel ilyen nem fordul elo. Egy rosszul karbantartott szunetmentes meg olyan, mintha ott se lenne.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Idejében visszaállítható backup az elsődleges, OS/FS másodlagos.

Másodlagosan viszont olyan FS javasolt, amiről viszonylag könnyedén visszanyerhető az adat esetleges gebasznál.
Tehát a százévente egyszer kaput, de akkor nagyon és az évente egyszer, de helyrepofozhatóan, főleg backup kiesése esetén, éveket, idegeket ment.
--
Solaris Express, Opera, OpenOffice.org, Yebol

( dblaci | 2011. 05. 02., h – 23:30 )

reiserfs. nem volt vele sose bajom. az fsck ja is nagyon jó, sérült winyóról is jól menthető, ha arról van szó...

( dash | 2011. 05. 02., h – 23:32 )

ReiserFS

2.4.1 óta a kernelben
első naplózó filerendszer a Linuxban (csak metadata; logikai vagy fizikai?)
készül a Reiser4, ezért a ReiserFS-t hívják Reiser3-nak is
online növelhető
offline zsugorítható
tail packing: belső töredezettséget csökkenti, de lassú
kis file-okra állítólag nagyon gyors (ez némileg ellentmond annak, hogy a tail packing lassú)
egy mérés szerint többszálú I/O esetén jelentősen csökken a sebessége
max. méret: 16 tebibyte
max. fileméret: 8 tebibyte
POSIX ACL, extattr
inode-ok lefoglalása dinamikus ("akárhány" file lehet rajta, valójában csak mintegy négymilliárd)
delayed allocation

Gyermekbetegségek (részben megoldva):

versenyhelyzetek
"tree rebuild" fsck során átverhető reiserfs-image-re emlékeztető file-lal
instabilitás
rossz angolsággal írt dokumentáció

Eszközök:

debugreiserfs
Általános diagnosztikai eszköz, mindenfélének a kiolvasására
reiserfsck
reiserfstune
journal-hangolás (méret, tranzakcióméret)
journal kihelyezése külső eszközre
resize_reiserfs
offline zsugorítás/növelés
online növelés
mkreiserfs
reiserfsprogs csomag

Fontosabb mount opciók:

notail: tail packing kikapcsolása (pl. a LILO kedvéért)
resize=blokkszám: remountoláskor használható a filerendszer növelésére

ext4

Az ext3 közvetlen utódjának szánják.
Az ext2 és az ext3 helyben upgrade-elhető ext4-re.
Állítólag stabil; nekem más a tapasztalatom.
Valódi modern fájlrendszer, minden fontos csengővel és síppal:
Részben 64 bites (lehetnek 16TiB-os fájljaink és 1EiB-os, vagyis 1048576TiB-os fájlrendszereink).
Extent-alapú allokációt használ.
Tud delayed allocationt.
A journalt ellenőrző összeggel védi, úgyhogy hibás journalt nem fog visszajátszani.
Nanoszekundumos felbontású időbélyegeket tárol.
Tárolja a létrehozás dátumát is (de egyelőre nem lehet használni).
Néhány optimalizáció miatt sokkal gyorsabban fsck-z, mint az ext3.
Elvileg online defragmentálható lesz.
32000-ről 64000-re nőtt az egy alkonyvtárban létrehozható alkönyvtárak száma (és gányolva efölé is mehetünk).
Támogatja a preallokációt: az fallocate() rendszerhívással előre lefoglalhatunk (jó eséllyel összefüggő) helyet egy fájlnak, amelyről tudjuk, mekkora lesz (ezt amúgy csak az xfs tudja jelenleg).

https://unixlinux.tmit.bme.hu/Filerendszerek

színes aláírás

( Fisher v | 2011. 05. 03., k – 08:30 )

Az a baj, hogy ez olyan mint a Canon-Nikon vagy bármelyik hitvita. Van akinek a reiser kakukkolt el (nekem soha), van akinek az ext4. Talán tíz éve használok reisert, azóta csak hwhiba miatt volt adatvesztésem.

A legújabb szerveremet némi tesztelgetés után ext4-el raktam össze. Fogalmam sincs, hogy el fog-e dőlni mondjuk holnap.

Viszont épp most ezt kaptam: Unable to determine IP address from host name "namesys.com"

Balgasagot? Az XFS-t nem lehet csokkenteni:I Sem online sem offline.
Bar az is igaz, hogy csak egyszer kellene jol megalmodni a teruleteket, es akkor nem kell atmereteznem 1-2 ev mulva.

Most veszek majd SSD-t, na majd akkor jol utanaolvasok, hogy melyikkel hogy megy? Meg melyiket ajanlgatjak majd ra. De ha semmi sem szol ellene, akkor marad a Reiser.

A borton meg kulon jo! Ha kell valami tole, akkor tudom, hogy hol talalom meg, sosem utazik el szabadsagra es raer bugokat javitgatni.

A namesys.com meg 2012-ben fog lejarni. A ket orosz dns szerver szunt meg, vagy van veluk bajsag.

( lberes (nem ellenőrzött) | 2011. 05. 03., k – 08:52 )

Ahogy irta valaki, ez gyakorlatilag hitvita, illetve szubjektiv tapasztalatok alapjan torteno ajanlas/ellenjavallat. Biztosan fogsz talalni 100 embert, akinek az egyik, es masik 100-at, akinek a masik valt be jobban. Hadd szalljak be en is is nehany tanaccsal:

- Red Hat supportos eletem soran egyetlen ugyfelre sem emlekszem, akinek ext3 miatti adatvesztese lett volna (mondjuk, hogy ~1000 gepes mintabol)
- reggeben (4-5 eve) nekem volt szoftveres adatvesztesem supportalt, HP gepen Debian alatti ReiseFS-en es XFS-en egyarant
- mostani gepeimen Red Hat es CentOS ext4 atomstabil es gyors
- ceges szerverre most vettunk XFS supportot Red Hattol nagy FS-re (>16 TB), eddig semmi gond

Konkluzio: ha van rendes vasad, rendes helyen, rendes supporttal, nem development kerneleket hasznalsz, nagyobb az eselyed, hogy mindened megmarad.

--
Fedora, RHEL, CentOS, virtualizáció, SELinux: http://sys-admin.hu

A rendes vas / support nem csak Linuxhoz, hanem ugy altalaban is kell.

En a Reiser-esek taborat erositem, nekem egy csomoszor halt mar meg ext[2-4] fajlrendszerem, kisebb-nagyobb adatvesztessel zarulva. Reisernel egyszer total tonkrement a fajlrendszer, de akkor mar a sajat tooljai se ismertek fel. Ezen felul mas gond nem volt soha vele. Az XFS-sel viszont volt mar par korom, backupbol helyreallitas lett a vege, plusz voltak olyan serult fajlok, amiket sehogy nem lehetett megreparalni (nem javitotta meg, nem torolte, en torolni nem tudtam). A vegen mar egesz sok.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Ha itt ez az, hogy leirja mindenki, wtf, hat jo:)

Nekem minddel volt mar adatvesztesem (jfs-sel nem, mert nem hasznaltam).

Persze tudok irni mind mellett jot es rosszat, csak az a kerdes, merre huz epp a szivem. Megemlitsem, hogy szar volt a hw? Vagy hogy az ext4 data=writeback -kel volt mountolva? Sok bullshitet fel lehet hozni..

NTFS-sel viszont meg nem volt. Produktiv szerverekre mindig azt teszek, ntfs-3g.

Ennyi hujeseget egy topicban...

tompos

nekem 1 dolgog nem tetszett régebben a reiser-ben: mount-kor mindenképpen rendbe akarta tenni magát, nem volt read-only opció, a logot rátolta.. ha meg nagyon kellenek az adatok a sérült fs-ből, akkor én először szeretnék mindent lemásolni a hibásról is, jön ami jön, fsck, aztán megnézni miből mi maradt.. na ezt nem lehetett a reiser-el megtenni.

( oszfer | 2011. 05. 03., k – 09:10 )

"Jelenleg éppen egy CentOS 5.6 döglött be rajta ext3 fájlrendszerrel."
Ha nem probléma, írnál erről kicsit bővebben? Tényleg érdekel, hogyn döglik be a CentOS 5.6...

Előre bocsájtom kb 5 éve nem foglalkozom rendszergazdai feladatokkal, mert 5 éve csak programozom. Szóval van egy szerver, ami nem ment 3 napja, ránézek, dobálja a diskkel kapcsolatos hibaüzeneteket -> újraindítás -> kernel panic, lvm van rajta, és nagyon jó lenne ha valahogy vissza tudnám nyerni róla az adatokat....:(

----------------------------
Előnevelt csirke kapható!

( andrej_ v | 2011. 05. 03., k – 09:55 )

Nemrég nézegettem az ext3 journal opciókat, hasonló igaz ext4-re is:
http://en.wikipedia.org/wiki/Ext3#Journaling_levels

Ahol fontos adat van, backup szerverek adat particióját is, ott egytől-egyig journal módban csatolom a filerendszert, nem érdekel ha kicsit lassabb.

Ext4:
http://kernelnewbies.org/Ext4
http://en.wikipedia.org/wiki/Ext4#Delayed_allocation_and_potential_data…

Az alkalmazáshoz igazított diszk alrendszert pedig nem lehet megspórolni, illetve próbálkozni lehet, de már többször szembesültem vele, hogy valahol szívás lesz a spórolásból.

( rootkit | 2011. 05. 03., k – 10:15 )

Érdekes "vita" tud kialakulni... Ismét csak azt tudom mondani, amit már más témával kapcsolatban is emlegettem, hogy nagyon fontos a súlyozás. A fájlrendszerek gyengéinek és erősségeinek figyelembevételekor nagyon pontosan meg kell határozni, hogy mire fogjuk használni.

Vegyesen használunk ext3-at (régebben inkább ReiserFS-t) és XFS-t. A felállás nálunk mindig a következő: a /boot ext3 ezen kívül van még egy kicsi partíció ext3-al session adatokhoz és a többi XFS. Elmondom miért.

Az XFS nagyon lassú, ha arról van szó, hogy sok "kicsi" fájlt kell piszkálni. Nem bírja a csiki-csukizást (állományok megnyitása-zárása). Nem bírja a nagy számosságú vagy nagy méretű fájlok törlését. Ellenben tud valamit, amit más FS nem: tegyél XFS-t egy MySQL adatbázis alá (jellemzően MyISAM) és eressz rá másodpercenként úgy 10000 műveletet, ebből legyen legalább 5000 írási művelet, futtasd legalább 10-15 percig közben monitorozod folyamatosan a teljesítményadatokat, különösképpen figyelj oda az IOWAIT-re és a folyamatos response time-ra (ne legyen benne megakadás egyáltalán). A teljesítménye közel lesz a /dev/shm teljesítményéhez! Mindez ext3-al vagy ReiserFS-sel röhejes adatokat fog produkálni, akárhogy tuningolod őket. Az ext3 pl. időnként egyszerűen blokkolni fog egy időre (akár másodpercek is lehetnek). Az XFS-sen csak a noatime opciót használjuk, semmi mást.

Más jellegű terhelés. Írj tesztet PHP session-teljesítmény méréséhez. Nem kell, hogy bonyolult legyen: egy sesstest.php nem csinál mást, mint minden meghívásakor betölti a session-t, inkrementál benne egy számlálót és visszaadja a kliensnek (és természetesen visszaírja a lemezre a záródáskor). Írj hozzá egy klienst, ami létrehoz legalább 30000 különböző session-t és random választva közöttük folyamatosan terheli velük a sesstest.php-t. Ajánlott más gépen futtatni a terhelőt. Nagyon fontos: az egész session kezelést Sharedance-en keresztül végezd (az rendesen nyitja-zárja a fájlokat). Nálunk ez volt a helyzet. Vicces lesz a dolog. Az XFS sebessége nagyságrendileg 1/10-e lesz az ext3-nak és a ReiserFS-nek. Nem elírás, közel 10x gyorsabbak lesznek a "kis" fájlrendszerek.

Rendkívül utálom a "hivatalos" benchmark-okat. Még sosem láttam egy igazán jót, ami több oldalról vizsgálta volna a fájlrendszereket. Amúgy szerintem elég ritka, hogy az embernek egy production szerveren létre kell hoznia 100000 darab 0 méretű állományt, vagy letörölni őket. Hogy másról ne is beszéljek.

Minden esetben, amikor valami teljesítményt teszteltek jusson eszetekbe, hogy nagyon nem szabad megbízni az előre készített benchmark-okban. A legtöbb egy bizonyos problémát jár csak körbe, vagy csak egészen rövid távú eredményeket vizsgál. A rendszereknek hosszú hónapokon keresztül kell üzemelniük elviselve - vagy kiküszöbölve - jelentős fragmentációt is (ebben mondjuk az XFS nagyon jó).

És akkor végül idéznék egy "nagy" nevet a szakmából: "98% of benchmarks are designed to confirm a decision already made" Jim A. Starkey
forrás: http://sourceforge.net/mailarchive/message.php?msg_id=17227375

Ez jo is, es mi is teszteltuk, webszervernel sokat gyorsitott, sot, meg mailszervert is probaltunk (az ugyebar elegge a "gyenge" oldala az apro fajlok miatt), es ott is relative jol telejsitett. Viszont a hibaturese/hibajavitasa az, amivel egyaltalan nem vagyok kibekulve. Hiaba a nagy teljesitmeny, ha az ember nem otthon, maganyban vagy dedikaltan uzemeltet egy szervert, hanem pl. shared hosting alatt, ott elengedhetetlen a megfelelo hibatures. Meg a backup-bol valo helyreallitas sem mindig engedheto meg. Ebben a tekintetben mind a Reiser, mind pedig az Ext3 felette all.
Rendszeresen elofordulo problema volt, hogy keletkeztek ugynevezett "hasznalhatatlan" fajlok egy-egy total leakadas soran (amikor mar csak a reset/force reboot gomb segitett). Ez altalaban egy javito fsck-zassal eltuntetheto. Nos, a XFS egyetlen toolja se tudta kiszedni oket. A gond az, hogy ez a mappalistazassal jaro dolgokat nagyon le tudta akasztani, plusz a fajl csak az ot tartalmazo mappa mozgatasaval volt "felreallithato".
En csak akkor hasznalnek XFS-t, ha valahogy ki van osztva, igy vedett az iro/olvaso rendszer hibaitol.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nekem reiserfs-el voltak a legdurvább adatvesztéseim (nem, nem a négyes kiadással). Manapság jfs-re és xfs-re szoktam formázni ha valamit kell.

xfs-el egyszer volt gondom, SCSI HDD-n. xfs_check(?) nem tudta javítani. Vagy még ez a tool vagy a Google ajánlott egy másikat. Azzal ugyan eltartott pár órát a dolog, de rendbetette.

jfs-el többször volt kisebb-nagyobb gondom, semmi egetverő. jfscheck visszaállította (asszem) az összes állományt, igaz az elérési útvonalak és nevek elvesztek. Mivel képekről volt szó, kevésbé zavart a dolog.

Lényeg, minden fájlrendszer sérülékeny. Azért vannak a rendszeres backup-ok hogy a hibák hatását minimalizáljuk.

( psc | 2011. 05. 03., k – 22:54 )

ha mar mindenki leirta, hogy mivel hogy volt adatvesztese, akkor en elmondanam, hogy nekem eddig mindossze ket fajrendszerrel nem volt adatvesztesem:
ntfs es hfs+.

keremkapcsojjaki.

( jailhouse v | 2011. 05. 16., h – 12:07 )

Köszönöm a tapasztalatokat, javaslatokat!

Végül az ext4 mellett döntöttem.

----------------------------
Előnevelt csirke kapható!