ext4 ve stabilních kernelech poškozuje data

V jádře 3.6.2 a novějších byla nalezena chyba v ext4, která způsobuje poškození nebo ztrátu dat. Chyba byla backportována i do řad 3.4 a 3.5.

24.10.2012 13:35 | Luboš Doležel (Doli) | Upozornění

Komentáře

[David Ježek]

3.3.8-desktop-2.mga2 ... uff (?)

[GeoRW]

3.0.0-20-generic

[Michal Fecko]

tak to mam 25x pruser...

[Atom321]

Podle té odkazované zprávy chyba nastává při mountu a krátce potom unmountu filesystému - když se za běhu nezaplní celý žurnál.

Pokud vám těch 25 strojů běží, tak na ně zatím nesahejte.

[Zopper]

Podle diskuze na archlinux.org (https://bbs.archlinux.org/viewtopic.php?id=151341#p1181122) a lklm.org by se měl problém projevit akorát při opakovaném mount-umount (pokud rychle umountnete jen jednou, tak to filesystém přežije jako obyčejné vypnutí stroje - obnoví se transakce podle žurnálu. Pokud se to ale stane dvakrát, tak v žurnálu bude nekonzistentní stav - budou tam data jak z prvního umountu, které pořád ještě nejsou zapsané, tak z druhého).

Aktuálně Ted Ts'o testuje, jestli vrácení dotyčného commitu, který za tím stojí, opravdu chybu odstraní a pokud jo, tak to ASAP pošle Linusovi (diskuze na lkml.org)

[Zopper]

Teď jak si to znova čtu jsem si všiml ještě něčeho... jak chápete ...if the journal's starting block is zero...? Jako že pokud je ten blok prázdný, nebo že je na nulové pozici -> celý problém se týká pouze prvního oddílu?

[andree]

kazdy oddil si cisluje bloky od 0, takze sa to tyka vsetkych oddilu...

[Tomáš]

LOL, včera se mi na fedora 16 upgradoval kernel na 3.6 a po jednom rychlém rebootu jsem už viděl hlášku "Run fsck MANUALLY"

[hermelin]

Dobrej pruser, jedna z nocnich mur systemoveho programatora Jeste ze jsem vcera naupgradoval gentoo-sources.

Dik za info

[Michal Fecko]

mozem zacat kontrolovat UPSky nesmie dojst k restartu

[hermelin]

Ja teda v drtive vetsine pouzivam XFS filesystem, ale pokud bych mel u EXT4 restartovat na opravene jadro udelal bych si full backup )

[Sten]

Nj, pro XFS je UPSka standard, bez kterého přijdete o data, teď to pouze backportovali do ext4

[hermelin]

Pravda pro XFS je durazne doporucovana UPS ale parkrat mi lehnul server bud ze se seknul nebo odesla UPS a XFS bez problemu ustal.

[gtz]

XFS je dostatečně robustní systém, který by toto měl ustát. Provozoval jsem na něm hodně velké pole, kdy na celém systému bylo právě XFS. Nebyl s tím problém takový, že by to xfs-repair nerozchodil. XFS bylo dříve doménou velkých FS, kde byly často osazovány řadiče s velkou cachí a ono nějakou dobu trvalo než se data zapsaly na diskový systém. Proto ta UPS.

[hermelin]

Ja XFS provozuji uz spousty let a jsem s nim maximalne spokojeny. Jinak pokud je nejaka RAM cache na radici a neni zalohovane jeji napajeni tak to asi neustoji zadny fylesystem

[gtz]

Hodně firem zapomíná na to, že ta baterka by se taky měla měnit

[SPM]

Spousta řadičů proto myslí za uživatele a když zjistí, že je vadná baterie, tu cache vypnou. Jelikož na takovém řadiči je typicky vypnutá i cache přímo na disku, tak je to taky mooc příjemné :)

[Sten]

No moje zkušenost je, že XFS má s jakýmkoliv nečekaným odpojením při zápisu problém, tedy přesněji ten souborový systém se nerozpadne jako Reiser, ale všechny soubory, do kterých bylo zrovna zapisováno, vyprázdní. Pokud jste zrovna aktualizovali libc nebo jádro, je o zábavu postaráno. To je prostě daň za bezkonkurenční výkon, ext (tedy až donedávna ) raději dělal věci pomaleji, než aby něco takového hrozilo.

[andree]

tato konkretna vlastnost (mazanie poskodenych suborov) je myslim zamer - holt autori preferovali konzistenci filesystemu pred obnovou poskodenych dat... Pri tom mnozstve cacheovania co XFS (udajne) robi je to celkom dobry napad asi, hlavne ak to mas na serveri. Trebars poskodena sql databaza asi moze byt vyrazne neprijemnejsia, nez ked ti vobec nenastartuje (ked bude jej file skrateny na 0B) - aspon vies ze to musis obnovit zo zalohy a hotovo.

[mankind_boost]

Not a bug, that's a feature!

[Sten]

Ano, je to záměr, právě proto je to stavěné na počítač s UPSkou. ext to řeší mnohem větším žurnálováním.

[SPM]

AFAIK ta míra žurnálování u ext je taky ovlivnitelná parametrem při mountu.

[lertimir]

Ten bezkonkureční výkon je jak v čem. rozhodně operace nad mnoha malými soubory a zvláště jejich mazání není to v čem XFS exceluje. Naopak práce s velkými soubory to mu velmi sedí.

[David Jaša]

Osobní zkušenost, nebo jen papouškuješ urban legends? Třeba tenhle heronův letitý zápisek naznačuje něco zcela jiného.

[lertimir]

Když jsem se před pár lety rozhodoval, tak jsem vycházel z testů na phoronixu. 2010. Novější je 2011 Takže jsem nasadil xfs na datové disky. Tam jsem velmi spokojen, ale to jsou disky na fotky a videa, nejmenší soubory se pohybují kolem 1-5 MB. Nicméně po výpadku proudu jsem měl s opravou potíže, a když bych neměl zálohy, byl bych o data přišel. Pokud je to "urban legends" tak ano papouškuji je.

[Sten]

Pomalé to je, než to načte metadata do RAM, ale to je každý trochu složitější souborový systém. Pak je to bleskové, mnohem rychlejší, než cokoliv jiného. Na dlouhodobější práci (file servery) je nepřekonatelný.

[jas]

Na file serveri vyhrava hlavne vdaka dobremu skalovaniu (scaling) (suvisi s tym, ze vacsina xfs podcasti funguje v style thread na jadro).

[Martin Mareš]

Když jsem si to před pár lety měřil, škálování mělo jednu velmi podstatnou chybu: globální zámek na velikost souboru, takže pokud jeden proces zrovna k souboru něco appendoval, ostatní procesy, byť chtěly jenom číst, stály. Možná už to někdo opravil, od té doby jsem to nezkoumal.

[jas]

Vykon, co sa tyka malych suborov, bol do nedavna skutocne zalostny, ale s prichodom delayed logging sa to zlepsilo a vykon je podobny ako pri ext4 (teda az na to mazanie, tam stale vyhrava ext4, tam uz ide o rozdiel v navrhu filesystemu).

Inak do buducnosti sa ocakava spomalenie v kode xfs kvoli novemu formatu hlaviciek, ktory bude zahrnat aj checksumy kvoli zlepseniu konzistencie dat (aj ked samozrejme pojde to aj vypnut a netyka sa to uz vytvorenych filesystemov).

[jas]

To, co popisujete je najskor sposobene tym, ze data boli zapisovane asynchronne (ziadny O_DIRECT a pod.). Vtedy maju data az asi 60 sekund, kym su skutocne zapisane. Nieco podobne nedokaze rozchodit ziadny filesystem (a osobne povazujem za horsie tie, ktore sa tvaria, ze ano). Po aktualizacii glibc alebo jadra je vhodne proste zavolat fsync. O nieco podobne by sa mal asi starat uz spravca balikov (nie som si tym uplne isty, ale myslim, ze napr. yum to robi).

Sem-tam sa najdu aj nejake nestastne chyby v kode xfs, ktore sposobia problemy v tychto situaciach, ale nejak moc caste nie su (a pokial ich mavate 'casto', tak sa bez bug reportov neopravia).

Mimochodom starsie jadra s xfs stracali menej suborov. Asi od 2.6.35 totiz xfs zacal z vykonnostnych dovodov podporovat nieco, comu sa vravi 'delayed logging'. V praxi to znamena, ze pokial pracujete s velkym mnozstvom malych suborov, tak sa zapisuju az po nejakom case spolocne. Toto sposobilo obrovsky rychlostny boost v pripadoch, ked mate velmi vela malych suborov (stale sa tym xfs dostalo len priblizne na uroven ext4). Nevyhodou je prave stracanie suborov vo vacsom rozmere (vyvojari xfs preto apeluju na pouzivanie fsync, ked je to potrebne - inak nema ako filesystem vediet, ze ide o velmi dolezite data).

Zaverom: prazdne asynchronne zapisovane subory po vypadku energii skutocne nie su povazovane za chybu file systemu. File system totiz nebol nijak varovany, ze sa o ne ma viac starat.

[tuxmartin]

Windowsaci vedi, proc cekaji na prvni servicepack

[AsciiWolf]

Já včera downgradoval gentoo-sources (z 3.6.2 na 3.6.1).

[lertimir]

openSUSE 12.2 má 3.4.11-2.16. Tak to nevím jestli do něj to také přešlo.

[gtz]

Já tam pro jistotu nechal

3.4.6-2.10

, update na 3.4.11-2.16 jsem viděl, ale prozatím nechci zasahovat do běžícího systému.

[Punny]

Ha a ja mam na CentOS jeste 2.6.18 :D tento dedecek si o upgradu muze jen nechat zdat :D

[Conyx]

nejspis ne, problem se podle me tyka az jader 3.4.14, 3.5.7, ktera byla podle changelogu olablovana ve stejnou dobu jako verze 3.6.2

[Kaacz]

Přesně tak, ve zdrojovkách 3.4.11-2.16 ta chyba není.

[Kaacz]

Ta věta "Chyba byla backportována ..." fakt nemá chybu. :) Bohužel mě smích hned přešel ...

[nyan]

Uz se tesim na maslofs... jenom 3x vic kodu...

[2X4B-523P]

asi už vím proč se my to rozsypalo na jednom notebooku, ale o nic důležitého nešlo a jinde mám ext3 a xfs

[ewew]

Ja zatiaľ používam ext3 a zatial som nemál problémy s týmto filesystémom. I keď nie je možné vylúčiť súhru nepriaznivých okolnosti, ktoré dokážu poškodiť aj takmer nezničiteľný filesystém.

Je na mieste otázka na aké médium zalohovať data a aký filesystém pritom použiť.

[mankind_boost]

Ja zálohuju do SquashFS (komprese XZ). Funguje skvěle :D

[SPM]

Hmm, fajn, ještě že jsem obě moje workstationy v tomhle týdnu upgradnul zrovna na 3.6.2 :)

[mikirc]

Vidim, ze se mi vyplatilo neresit duvod chyby v kubuntu, proc nechce aktualizovat jadro :D asi vedelo ze neco prijde :D :D

[alfonz mucha]

Docela jsme rád, že jsem všude nechal ubuntu 12.04 LTS a nic neaktualizoval, asi by mě to trochu naštvalo.

[jyrki]

Hmmm, tak bezim 3.6.2-1, ale nepozoroval jsem problem. Dnes jsem upgradoval na 3.6.3 a trosku jsem se vylekal zda mam vubec vypinat vecer PC. Ale toho co jsem nasel si nemyslim ze by se melo neco pokazit.

Even though it is a severe bug the chances of it happening to you are low. You have to unmount and immediately remount an EXT4 partition twice in a row for it to happen. On a normally operating system that is not a normal thing to happen. Just wait on your desktop for 5 minutes before rebooting again.

At tak ci onak, asi nainstaluju LTS kernel kde by tato chyba byt nemela...

[Zopper]

Akorát jsem to napsal o kus výš tady - opravdu jde o problém, který by se měl projevit akorát při dvojnásobném mount-umount a ani pak ještě nemusí k ničemu dojít, pokud budete mít štěstí.

[jyrki]

Ja to cetl a tu diskuzi take, nicmene mam sva data rad a ackoliv verim ze se nic se soucasnym jadrem nestane, LTS vidim jako vetsi jistotu.

[Petr Ježek]

Já na Archu hlasím: bez problému.

[Petr Tomášek]

Hm, zajimave cteni, jak k chybe doslo (a jak za ni muze prastary komentar)...

[Ondroid]

Pamatuju že něco podobného se stalo kdysi v linuxovém středověku kolem jádra 2.4.4 nebo tak nějak.

[Peter Fodrek]

staci as dat paramter commit v fstab na 1 a malo by to byt OK, ak si dobre pamatam

[Yontalcar]

Tak nakonec asi o nic nejde: https://plus.google.com/117091380454742934025/posts/Wcc5tMiCgq7