Dotaz: soubor se změnil na adresář - chyba souborového systému?

Používám na desktopu Thunderbird, pošta z různých mailových účtů se ukládá do adresářů na vyhrazeném oddílu Raid1 z 2x ext3 (SSD disky).

U dvou účtů se mi stalo, že Thunderbird přestal stahovat poštu a napsal "Unable to write to the mail box. Make sure the file system allows you write privileges, and you have enough disk space to copy the mailbox"

Když jsem začal prověřovat to diskové pole, tak jsem zjistil, že v adresářích těch dvou účtů zmizel soubor "Inbox" a místo toho se tam objevil _adresář_ se stejným názvem (žádný obsah).

Předpokládám, že je to chyba souborového systému? předpokládám, že by to neměla být chyba disku, nebo ano?

a dá se to nějak opravit?

nevím, jak bych měl správně postupovat, když je to raid1, jestli ho mám napřed odpojit, oddělit disky a nechat je fsck opravit jednotlivě?

Odpovědi

[ewew]

V prvom rade musíš dať filesystém do režimu Read-olny a potom je možnosť pokúsiť sa o obnovu.

Aké tam máš disky ? Výrobca, séria a atď. Prilož výpis príkazu mount. V raid 1 je jedná vlastnosť, ktorá spôsobi, že vplyvom chyby na jednom disku sa prenesie na druhý disk. Šance na obnovu neviem definovať.

Mne sa raz podarilo na ext3 filesystéme obnoviť súbory ale to bolo okamžite nastavení ro mód a ako ďalšie plus bol nastavení príznak u v rozšírených atributoch.

[klklj]

disky jsou OCZ Agility AGT3 25SAT3 120G

výpis mount:

/dev/sda1 on / type ext3 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
none on /dev type devtmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
/dev/sda3 on /virtualbox_ssd type fuseblk (rw,nosuid,nodev,allow_other,blksize=4                                                              096)
/dev/md2 on /datad02ssd type ext2 (rw)
/dev/md1 on /datad02 type ext2 (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev                                     

)

ten filesystém jsem spletl, je to ext2

[R]

Nestalo sa ti to nahodou po nekorektnom vypnuti/restarte? ext2 nema proti tomu ziadnu ochranu. Musi sa urobit fsck.

[Michal Kubeček]

Jiné filesystémy proti tomu také žádnou ochranu také nemají. Představa, že nás žurnál nějak chrání před poškozením metadat nebo dat při nekorektním ukončení, je jedním z tradičních omylů. Ve skutečnosti je jediný rozdíl v tom, že u žurnálovacího filesystému je uvedení do konzistentního stavu podstatně rychlejší.

[R]

V zurnale su vsetky potrebne informacie na uvedenie filesystemu do konzistentneho stavu. Ale bez zurnalu fsck tieto informacie nema, musi ich roznymi sposobmi zistovat - hladat po disku, pouzit defaultnu hodnotu alebo jednoducho subor skratit, nasledne hladat data, ktore nikomu nepatria a tie presunut do lost+found.

Priklad z praxe: stahujem subor z webu a urobim tvrdy reset. Ked mam zurnal (ext3 data=ordered), stratim len malu cast suboru na konci a mozem pokracovat v stahovani. Ked zurnal nemam, tak bude pravdepodobne cely subor v prdeli.

[Michal Kubeček]

Priklad z praxe: stahujem subor z webu a urobim tvrdy reset. Ked mam zurnal (ext3 data=ordered), stratim len malu cast suboru na konci a mozem pokracovat v stahovani. Ked zurnal nemam, tak bude pravdepodobne cely subor v prdeli.

To je dost optimistická vize a obecně něco takového rozhodně tvrdit nelze (ani jednu část).

[Michal Kubeček]

V zurnale su vsetky potrebne informacie na uvedenie filesystemu do konzistentneho stavu.

Přesně: do konzistentního stavu. Ale nikde nemáte záruku, že to bude právě ten, který byste chtěl.

[gngl]

Já si to onehdá vysvětlil tak, že žurnál tady není od toho, abych nepřišel o otevřené soubory, ale od toho, abych nepřišel o všechny ostatní.

[jekub]

ldh

[jklkl]

Nestalo sa ti to nahodou po nekorektnom vypnuti/restarte? ext2 nema proti tomu ziadnu ochranu. Musi sa urobit fsck.

to bohužel nevím, přišel jsem na to v podstatě náhodou, protože se to stalo u mailového účtu, který používám na různé registrace, takže se sice stahuje s ostatními, ale čtu ho jen jednou za čas

[ebik]

Pokud raid nehlásí chybu, tak lze předpokládat, že na discích je stejný obsah. Pak jde spíše o chybou FS/jádra a ne chybou hw. Nejlepší je asi udělat zálohu souborů na jiné místo a pak začít opravovat FS přímo na raidu, stejne jako by to byl jeden disk. Při troše štěstí se obsah inboxů objeví v lost+found. Při troše smůly to není chyba FS ale vyrobila to tam nějaká špatně napsaná aplikace. Pak lze zkusit ještě obnovu smazaných souborů, ale moc tomu nedávám.

[klklj]

ta chyba filesystému je velmi pravděpodobná, ale nechtěl jsem tomu ze začátku věřit (Ubuntu 10.4, už je to tak tři roky, a chyba(?) by se objevila až teď)

zálohu teď ještě kopíruju na jiný PC, pak se do toho pustím.

V těch poškozených Inboxech nejde o data, mám průběžné zálohy, ale potřebuju vědět, co se děje.

Jediná aplikace, která do toho sahá, je Thunderbird,

Asi určitě je to chyba filesystému, protože jsem jeden Inbox našel v podadresáři jiného e-mailového účtu s velmi podobným názvem (?!)

Asi se to špatně představí, ale vypadá to zhruba takto:

- adresář novakova@domena.cz ztrail soubor Inbox, místo něj je tam adresář Inbos s nulovým obsahem

- v adresáři novak@domena.cz (který je jinak OK) se objevil další adresář novakova@post v něm ten "ztracený" Inbox je

Když jsm smazal ten adresář, který tam neměl být, a zkopíroval ten Inbox odjinud, tak se tam ta pošta objevila.

Navíc ten adresář "novakova@domena.cz" se objevil ještě na dalších místech disku.

Tak teď přemýšlím, jestli bych neměl oba disky a pole zformátovat, a potom na ně nakopírovat ze zálohy, ale právě se bojím toho, aby to nebylo hardwarem a nepokračovalo to.

[Peter Golis]

FS ext2, to je ešte podporované? Pred pár rokmi sa mi vysypal a zistil som že pri štarte systému, po vyskytnutí sa nekonzistencie robí iba prehranie neexistujúceho žurnálu a označenie že disk je OK. Takže sa mi tam množili chyby ktoré mi systém veselo ignoroval. Distribúcia bola Gentoo x86, ale to je vedľajšie.

Takže držím palce.

[pavlix]

FS ext2 je podporovaný pokud vím driverem ext4, popřípadě jde u ext4 podle všeho žurnál vypnout.

[Peter Golis]

Nemyslel so podporu v ovládači , ale podporu v jadre pri pripájaní disku. Mne to postupom času podobne odpálilo údaje na disku. Ber to tak, že poukazujem na možnú príčinu. Záchrana v mojom prípade nebola potrebná keďže to bol sandbox,teda menej ako testovací stroj.

Holt, s nástupom TB diskov sa začalo vynucovanie žurnálu kôli dľžke trvania rutinne kontroly konzistencie súborových systémov.

[pavlix]

Nemyslel so podporu v ovládači , ale podporu v jadre pri pripájaní disku.

Nemůžu říct, že bych chápal, co se tu snažíš říct.

[klklj]

FS ext2, to je ešte podporované? Pred pár rokmi sa mi vysypal a zistil som že pri štarte systému, po vyskytnutí sa nekonzistencie robí iba prehranie neexistujúceho žurnálu a označenie že disk je OK. Takže sa mi tam množili chyby ktoré mi systém veselo ignoroval. Distribúcia bola Gentoo x86, ale to je vedľajšie.

Aha, netušil jsem, jak moc jsem už zastaral

Tak to zkusím obnovit "ze studijních důvodů" a pak to celé zformátuju nově na ext3. Co bude chybět, doplním ze záloh.

Takže držím palce.

Díky

[tom]

FS ext2, to je ešte podporované?

Ext2 je uplne normalne podporovany, muzete to snadno zjistit pohledem do logu v gitu. Navic k pripojeni ext2 FS muzete pouzit i ext3 a ext4 driver.

Pred pár rokmi sa mi vysypal a zistil som že pri štarte systému, po vyskytnutí sa nekonzistencie robí iba prehranie neexistujúceho žurnálu a označenie že disk je OK. Takže sa mi tam množili chyby ktoré mi systém veselo ignoroval. Distribúcia bola Gentoo x86, ale to je vedľajšie.

To vubec neni vedlejsi - to, ze se na rozbitem FS nespustil fsck, je chyba distribuce, protoze ta je za to zodpovedna.

[Peter Golis]

Jadro mi našlo pri štarte dirty FS EXT2 a vypísalo "recovering journal" . Podobne sa choval fsck pri štarte a prechádzaní fstab. Po vytvorení žurnálu cez tune2fs to už bolo ochotné robiť kontrolu a našlo dosť veľa chýb. Presné chybové hlášky z tohoto problému som si nezachoval, tie údaje boli pre mňa takmer bezcenné. Takže som mávol rukou zo slovami že už chapem prečo vývojári systému slušne povedané preferovali súborové systémy s žurnálom v čase gigantického nárastu kapacity diskov. Nepredpokladal som, že to pri rutinnej kontrole konzistencie aktivujú natvrdo. Dosah u mňa bol na systéme SBC s 10G diskom a pekelne pomalým radičom.

No, ak je k dispozícii pôvodný obraz pokazeného FS, tak by som v Tvojom prípade zvážil jeho kópiu, vytvorenie žurnálu a opravu konzistencie. Niekedy nemajú zálohy dostatočnú frekvenciu a v Tvojom prípade sa asi stiahnutá pošta na poštovom servri neuchováva nejakú dobu po jej stiahnutí na diskový alebo terminálový server a jej následnom zmazaní poštovým klientom.

Mimochodom, stalo sa mi to pred asi piatimi rokmi, a nepredpokladám že sa spetne aktivovala pôvodná a korektná funkcionalita. Disková kapacita odsunula niektoré súborové systémy bez žurnálu za okraj záujmu.

[Michal Kubeček]

Jadro mi našlo pri štarte dirty FS EXT2 a vypísalo "recovering journal".

Jste si jistý?

mike@unicorn:~/work/git/kernel-upstream> grep -r 'recovering journal' *
fs/gfs2/ops_fstype.c:                           fs_err(sdp, "error recovering journal %u: %d\n",

Ale především: ext2 žádný žurnál nemá a ani mít nemůže, ext2 není žurnálovací filesystém. Pokud na něm žurnál vytvoříte, uděláte z něj ext3.

[Peter Golis]

I keď to bolo 5 rokov dozadu, tak som si istý podstatou chyby. Ale, ako som už spomínal, tak presným znením už nie. Takže použitie grep je trošku mimo.

[R]

Trochu mimo si ty, pretoze ext2 nema zurnal!

[Peter Golis]

Áno, ja viem. A preto som si ho vybral. Ale mimo si Ty keďže si si neprečítal načo reaguješ. Vieš to?

[tom]

I keď to bolo 5 rokov dozadu, tak som si istý podstatou chyby. Ale, ako som už spomínal, tak presným znením už nie. Takže použitie grep je trošku mimo.

+-10 let sleduju patche, co jsou zarazeny do mainstreemu a mohly by se tykat nasich zarizeni, na kterych pouzivame mimo jine i ext2 a zadneho takoveho problemu jsem si nevsiml. Nerikam, ze to neni mozne, ale je mnohem pravdepodobnejsi, ze jste si to rozdrbal sam a nebo to byla chyba ve startovacich skriptech v distribuci.

[Peter Golis]

Áno, nekonzistenciu som si spôsobil sám nútenými reštartami. Ale problém bol v neodhalení dirty FS jadrom a ani priamym spustením fsck na daný prípojný bod.

Ale, načo sa ja opakujem.

[Michal Kubeček]

Proč do toho pořád pletete jádro? A co je to "neodhalení dirty FS"? Flag "dirty" je pouhý příznak v superblocku, který se nastaví při (rw) mountu a shodí při odmountování nebo přemountování read-only, na tom není co odhalovat. To, že se při startu zkontroluje dirty flag a případně provede check, řeší init skript distribuce, ne jádro. Přičemž e2fsck defaultně pouze zkontroluje dirty flag a když není nastaven, vlastní kontrolu neprovádí - což máte napsáno v dokumentaci. Pokud máte podezření na poškozený filesystém, máte ho zkontrolovat ručně (a samozřejmě s -f).

A hlavně - už asi potřetí - ext2 není žurnálovací filesystém, tedy pokud vám jakýkoli nástroj tvrdil, že na něm obnovuje žurnál, tak si o něm rozhodně nemyslel, že je to ext2, takže jste měl problém v konfiguraci.

[Peter Golis]

Áno, ako som spomínal, ak to som už urobil. A fsck sa so mnou začal v tom prípade korektne baviť až keď som pre ten disk vytvoril žurnál a tým pádom ho skonvertoval. A jadro začalo korektne detekovať dirty fs pri pripojení tiež až keď tam bol žurnál a z toho disku sa stal ext3. Mýlim sa keď zopakujem že som to tu písal? Alebo si niečo pletiem keď hádžem hrach na stenu a bavím sa s človekom trpiacim selektívnou slepotou?

[Michal Kubeček]

Alebo si niečo pletiem keď hádžem hrach na stenu a bavím sa s človekom trpiacim selektívnou slepotou?

No, když už jste začal s tou selektivní slepotou a házením hrachu na zeď… Už mne nebaví pořád dokola upozorňovat na zjevně nepravdivá tvrzení ve vašem popisu problému. Takže se omezím na obecnou radu: naučte se při popisu problému rozlišovat mezi fakty a vašimi doměnkami. Jinak riskujete, že ten, kdo ho bude číst, při určitém počtu zjevných nepravd přestane zkoumat, co by mohla být pravda a co si pouze myslíte, a bude se věnovat něčemu jinému.

[Peter Golis]

Áno, tou selektívnou slepotou som si istý. Vyššie som spomínal, že so mal pred pár rokmi podobnú chybu kde mi jadro ignorovalo príznak že súborový systém nebol korektne odpojený a userspace nástroje nerobili rutinnú kontrolu pri štarte systému aj keď to mali definované. A že rutinná kontrola začala fungovať až keď som tomu FS vytvoril žurnál. Tak isto som spomínal, že si nepamätám presnu hlášku. To chovanie systému sa nedalo ani prehliadnúť a ani zabudnúť. Takže argumentovanie vyhľadávaním presného reťazca a omielanie ze ext2 nemá žurnál je rovnako scestné ako prehliadanie spomínaných vecí.

No nič. Jedno je teória s prianím ako by to malo fungovať, a druhé je prax.

[Michal Kubeček]

V okamžiku, kdy pořád dokola připisujete jádru činnosti, které nedělá a dělat nemá, a kdy zatvrzele ignorujete fakt, že ext2 žádný žurnál nemá a že tudíž pokud na něm někdo chtěl žurnál "obnovovat", pak jedině v důsledku chybné konfigurace, se nemůžete divit, že beru s odpovídající rezervou i ostatní informace, kterými si jste stejně jistý jako těmi, o kterých vím, že nemohou být pravda.

A tímto konstatováním s tímto threadem končím, tedy přinejmenším do chvíle, než začnete rozlišovat mezi fakty a doměnkami (dojde-li k tomu).

[Peter Golis]

Popisoval som okolnosti ktoré mi dopriali podobnú zábavu ako mal zadávateľ témy. A som rád, že som obviňovaný z napríklad ignorácie faktu že ext2 nemá žurnál. A tak isto som rád, že som obviňovaný z toho, že som si pokazil nejaké skripty alebo nastavenia. Bez ohľadu na to, že, znovu opakujem, po vytvorení žurnálu pre inkriminovaný disk, a teda jeho zmenou z ext2 na ext3 mi začala fungovať rutinná detekcia poškodeného súborového systému a tak isto došlo k jeho oprave ktorá bola bez žurnálunemožná.

Ale, je mi ľúto, ze sa som nou už nechce baviť tak veľký odborník čo žije v predstave že všetko funguje tak ako si predstavuje. A preto radšej ignoruje poskytnuté informácie. S nimi by sa mu ten sen zahmlil.

No, je pravda že som tieto veci spomínal ako dosah rizika ktoré mi odpálilo údaje s podobnými príznakmi ako zadávateľovi témy. A tak isto je pravda, že som sa nehal zatiahnúť do zbytočnej diskusie s človekom čo ešte nevidel dlhodobú prevádzku preťaženého jednoúčelového stroja.

[Michal Kubeček]

Pak jde spíše o chybou FS/jádra a ne chybou hw.

Já bych s tou Occamovou břitvou šel ještě trochu dál a místo hypotézy, že je v široce používaném a léty prověřeném filesystému ext3 je chyba způsobující, že se tazateli náhodně obyčejné soubory mění na stejnojmenné adresáře (ale jen tazateli a jen u mailboxů), bych začal spíš s daleko pravděpodobnější hypotézou, že je to chyba userspace aplikace, např. nepovedený nebo násilně přerušený pokus o konverzi mailboxu na maildir či jiný formát pracující s adresářem.

Zvláště pak píše-li tazatel věci jako

na vyhrazeném oddílu Raid1 z 2x ext3 (SSD disky)

On se snad dělá RAID nad filesystémy? (Nepočítám BtrFS, to je úplně jiná kapitola.) RAID (md) sestavuje pole z blokových zařízení a teprve na výsledném blokovém zařízení se vytváří filesystém.

[klklj]

Já bych s tou Occamovou břitvou šel ještě trochu dál a místo hypotézy, že je v široce používaném a léty prověřeném filesystému ext3 je chyba způsobující, že se tazateli náhodně obyčejné soubory mění na stejnojmenné adresáře (ale jen tazateli a jen u mailboxů), bych začal spíš s daleko pravděpodobnější hypotézou, že je to chyba userspace aplikace, např. nepovedený nebo násilně přerušený pokus o konverzi mailboxu na maildir či jiný formát pracující s adresářem.

jediná aplikace je Thunderbird, o žádné konverzi nic nevím (chci tím říct, že se to stalo při normálním používání desktopu, žádný upgrade/přechod na jiný poštovní program apod.)

On se snad dělá RAID nad filesystémy? (Nepočítám BtrFS, to je úplně jiná kapitola.) RAID (md) sestavuje pole z blokových zařízení a teprve na výsledném blokovém zařízení se vytváří filesystém

Asi jsem to popsal špatně, myslel jsem to tak, že jsem měl dva disky formátované na ext3 a ty jsem přes Webmin spojit do raid1 a na něm byla data (to pole se v příkazu mount vypisovalo jako ext2, ale disky, na kterých jsem je sestavil, byly ext3).

[Michal Kubeček]

jsem měl dva disky formátované na ext3 a ty jsem přes Webmin spojit do raid1 a na něm byla data

To nebyl dobrý nápad. Driver md potřebuje na zařízení uložit hlavičku s metadaty (persistent superblock), takže i když to nejspíš na první pohled vypadalo, že je filesystém v pořádku (na rozdíl od starších verzí se dnes defaultně metadata neukládají na začátek), tak v pořádku nebyl. A navíc dalším používáním mohlo docházet ke vzniku nových chyb.

[Aleš Kapica]

Tohle je typický problém souborových systémů typu ext. Pokud se ti tohle stane, tak už ti nepomůže ani svěcená voda. Resp. Jediné co pomůže, je provést ruční opravu. Tzn. chybějící adresáře a soubory znovu vytvořit. Rozuměj - vyhledat a přesunout z lost+found data z jednotlivých inodů, které fsck našel. Zkrátka práce pro vraha.

K problému totiž dojde tehdy, pokud se poškodí tabulka, ve které jsou uloženy informace o inodech. U reiserfs ani btrfs jsem se s podobným problémem nesetkal nikdy. Ty totiž udržují metadata jiným způsobem. U ext systémů se mi to stalo už několikrát a obvykle to skončilo reinstalací a obnovou dat ze zálohy.

[2X4B-523P]

nikdy se mi to nestalo, ale podívej na TOTO:

A good rule of thumb is that it is okay if you have a few strange files in your profile since they are probably either due to an add-on or this article not being updated yet, but any time you find a SQLite file replaced by a directory with the same name its probably due to a bug.

[Aleš Kapica]

Dík, ale na mých souborových systémech toho leží obvykle mnohem víc, než profil Thunderbirdu

[klklj]

díky moc, něco takového jsem potřeboval na uklidnění - pokud to můžu považovat za chybu Thunderbirdu, tak s tím můžu žít, než kdybych se klepal, jestli mi neodchází disky jako takové a s nimi i jiná data než ta pošta

[Michal Kubeček]

Hm… :-)

[ikar]

Pochybuji, že to způsobila filesystému (na 99.99 % ne). Spíše to vidím upgrade nebo změnu konfigurace Thunderbirdu, který začal místo mailbox používat maildir a pokusil se o nějakou nepodařenou migraci. Fsck je v tom případě nanic, není co opravovat.

[vdusek]

Ta chyba bude u klávesnice

na vyhrazeném oddílu Raid1 z 2x ext3 (SSD disky)

Nejprve bych dal do pořádku filesystémy a pak začal řešit něco dál

[R]

Thunderbird dodnes oficialne maildir nepodporuje, takze urcite to automaticky nekonvertoval. Nejaka podpora maildiru tam je, ale treba to zapnut niekde v about:config a zalozit novy ucet (automaticku konverziu to robit nevie).

[ikar]

Dobrá, o vině Thunderbirdu se hádat nebudu, ale stalo se nám na serveru něco podobného a nebylo to chybou filesystému. Udělal to imapd, který to obsluhuje na serveru. Ale dle autorů imapd to je vyvoláno špatnou akcí klienta. Dokonce se to dá na netu najít, co se má v klientovi nastavit, aby k tomu nedocházelo.

[Aleš Kapica]

Pochybuji, že to způsobila filesystému (na 99.99 % ne).

Jo? Tak mohu přidat hned další případ. O tomto víkendu odešel v raid6 jeden ze čtyř disků. V poli byl SPARE, takže bych nečekal žádný problém. První varování bylo, že zmizela binárka pro tail, přesto že měla replikace proběhnout v pořádku. V systému visela hromada procesů, které nešlo odstřelit a po restartu už systém díky rozbité ext4 nenajel - grub nenašel potřebné soubory.

Fsck.ext4 ze systemrescuecd pak dokonal dílo zkázy a celé je to zralé na reinstalaci, protože jenom pánbů ví, co bylo v inodech, které šly do kytek. Naštěstí jde pouze o systémový disk. Zákeřná kombinace? Raid+LVM+Ext4 K tomu bych jen poznamenal, že u reiserfs se mi takovým způsobem systém nikdy nerozbil.

[ikar]

Ve vašem případě odešel disk v Raid6, autorovi se "změnil jeden soubor na adresář" v Raid1, disky byly OK (pokud SSD vůbec mohou být OK). Nepovažuji tento váš příklad za příliš vhodný. Ale soucítím s vámi - výrobci bych utrhnul hlavu a řadič bych mu našrouboval do díry v krku. Když je špatné železo, tak je fuk, zda tam je reiser nebo ext. (I když Raid+LVM+Ext4 je už takových vrstev na sobě, že je div, že to vůbec funguje).

[Aleš Kapica]

Podstata není v tom jak problém vznikl, ale jakým způsobem ho fsck řeší. U ext systémů končí oprava hromadou anonymního smetí v lost+found. Tohle slušné souborové systémy nemají dělat a také nedělají.

[ikar]

Hm. Kdo je slušný, ať hodí kamenem. Některé fs nemají nástroje na opravu vůbec, u jiných zůstanou soubory sice neanonymní, ale zato nulové délky, člověk si nevybere. Já mám asi s ext štěstí. Poničený systém ext2 naposled před patnácti léty, fsck.ext2 to bez problémů opravil, poškozené ext3 a ext4 jsem nezažil nikdy. A to jsem už přes disky na desktopech a serverech prohnal hezkou kupu terabytů.