ext4 - ano či ne?

[macu]

zítra má vyjít FR Ubuntu 9.04, stále ještě přemýšlím, zda nedát na / fs ext4 (na /home chci ponechat ext3)....četl jsem pár článků o problémech s ext4....doporučujete / formátovat na ext4 či raději počkat až na 9.10 (používám 64bit verze Ubuntu)

[MartenP]

Používám už od mých Sidovských dob a nemohu si stěžovat. Žádný problém.

[kkaarreell]

kdyz nevis, tak zustan u ext3... at pak nejsi nestastny, ze ztratis data kvuli blbe napsane aplikaci. ;-)

[macu]

a stalo se vám někdy, že by jste přišel o data?

[kkaarreell]

mnohokrat.. nejcasteji kdyz prijdu k ranu domu ozraly a dostanu neodbytnou potrebu procistit filesystem od zbytecnych souboru.

[Sešívaný]

Silně pochybuju, že by se Ext4 dostalo do stabilní větve jádra a mělo problémy typu ztráta dat. Linux je nasazován tam, kde je ztráta dat mnohem větší pohromou než na domácích počítačích, proto je to podle mě fakt dobře otestované. Já jedu na jádru 2.6.30 a naprosto bez problémů, ale myslím, že to bude naprosto bez problémů i na 2.6.28, které je je v Jaunty.
Oproti Ext3 a ReiserFS, které jsem používal dříve, mi to přijde subjektivně rychlejší, minimálně start systému je s Ext4 o cosi rychlejší.

[igst]

Ext4 na celé partition používám od minulého pátku , od instalace Kubuntu 9.04 RC. Ztráta dat zatím žádná i když uznávám, že jako relevantní testovací vzorek ten necelý týden neobstojí 

IMHO jsou diskové operace subjektivně rychlejší, rychlejší je i celý systém, to ovšem nemusí být pouze zásluhou ext4, ale celkového zrychlení JJ a KDE4 oproti předchozímu II s KDE3.5.

[macu]

tudíž už je vše opraveno a nemusím se bát tohoto bugu?

http://www.h-online.com/open/Possible-data-loss-in-Ext4--/news/112821
https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781

[igst]

To je známý problém s opožděnou/odloženou alokací, kdy (zjednodušeně) souborové změny jsou zapsány pouze v žurnálu a k promítnutí na disk dojde až s určitým časovým odstupem. Nechtělo se mi pročítat celou diskuzi, ale některým uživatelům se při pádu systému "vynulovaly" některé soubory, často bohužel konfigurační. Další diskuze se vedla, zda je to opravdu problém ext4, jelikož podobné metody "delayed allocation" používají téměř všechny moderní souborové systémy, nebo je to problém nevhodně napsaných aplikací, které hřešily na to, že u ext3 docházelo k zapsání změn na disk v řádu sekund. V launchpadu je nakonec chyba označena jako opravená a patch by měl být dostupný v jádru 2.6.30.

[macu]

ano,to je právě to, že oprava je až v poslední verzi jádra....nicméně jsem četl, že by mělo být pořešeno ve FR Ubuntu 9.04, tak snad to bude OK

[Yontalcar]

Silně pochybuju, že by se Ext4 dostalo do stabilní větvě jádra a mělo problémy typu ztráta dat.

<< POSIX nespecifikuje chování při pádu systému takže je toto chování (ztráta dat) naprosto v pořádku

To je známý problém s opožděnou alokací, kdy (zjednodušeně) souborové změny jsou zapsány pouze v žurnálu a k promítnutí na disk dojde až s určitým časovým odstupem. Nechtělo se mi pročítat celou diskuzi, ale některým uživatelům se při pádu systému "vynulovaly" některé soubory, často bohužel konfigurační. Další diskuze se vedla, zda je to opravdu problém ext4, jelikož podobné metody "delayed allocation" používají téměř všechny moderní souborové systémy, nebo je to problém nevhodně napsaných aplikací, které hřešily na to, že u ext3 docházelo k zapsání změn na disk v řádu sekund. V launchpadu je nakonec chyba označena jako opravená a patch by měl být dostupný v jádru 2.6.30.

<< AFAIK Btrfs tento problém nemá
problém vzniká tím, že ext4 provede přejmenování (na disku) dříve než zápis dat (na disk); alespoň takhle jsem to pochopil z několika diskuzí

[kkaarreell]

Problem byl zpusoben tim, ze mnohe aplikace pri spusteni smazaly sve konfiguracni soubory (ci pri otevreni soubory jine), aby je nasledne zase ulozily. Nicmene POSIX nespecifikuje, kdy se maji data fyzicky zapsat na disk, pokud si to aplikace explicitne nevyzada (fsync) - coz mnohe programy nedelaji. Pokud pak program spadne, nejsou data na disk fyzicky zapsana. Nicmene toto neni "chyba" filesystemu, ale vcelku ocekavatelna a pochopitelna vlastnost. Dovedeno ad absurdum si podobne nemuzu byt jist, zda harddisk data doopravdy zapsal a ze je jen nedrzi ve sve vyrovnavaci pameti.

Podobneho chovani docilim na mem notebooku s ext3, kdyz pri mountovani disku nastavim sync time na 300 vterin, abych neustale nehrabal na disk (proste verim, ze mi nezatuhne system a na notebooku nahly vypadek napajeni neresi).

[Yontalcar]

Problem byl zpusoben tim, ze mnohe aplikace pri spusteni smazaly sve konfiguracni soubory (ci pri otevreni soubory jine), aby je nasledne zase ulozily. Nicmene POSIX nespecifikuje, kdy se maji data fyzicky zapsat na disk, pokud si to aplikace explicitne nevyzada (fsync) - coz mnohe programy nedelaji. Pokud pak program spadne, nejsou data na disk fyzicky zapsana. Nicmene toto neni "chyba" filesystemu, ale vcelku ocekavatelna a pochopitelna vlastnost. Dovedeno ad absurdum si podobne nemuzu byt jist, zda harddisk data doopravdy zapsal a ze je jen nedrzi ve sve vyrovnavaci pameti.

Podobneho chovani docilim na mem notebooku s ext3, kdyz pri mountovani disku nastavim sync time na 300 vterin, abych neustale nehrabal na disk (proste verim, ze mi nezatuhne system a na notebooku nahly vypadek napajeni neresi).

<< Proč by měly ty aplikace _mazat_ ty konfiguráky? K čemu by jim to bylo? Ony si většinou vytvoří vedle nový soubor a po uzavření jej přejmenují přes ten starý. (viz https://bugs.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/54) - toto by mělo zaručit, že data na disku budou buď ty stará, nebo ty nová; ale díky tomu, že commit metadat (vytvoření souboru a přejmenování) proběhne separátně a dříve než commit dat, disk skončí ve stavu, kdy starý soubor už není, ale data nového ještě nejsou zapsaná

[kkaarreell]

proc je mazou se me neptej, ja nikde nerekl, ze je to "spravne" chovani.
http://www.root.cz/zpravicky/ext4-pomohlo-odhalit-spatne-napsane-aplikace/

[Prsatá blondýna]

na ext4 jedu na ecku uz asi tyden a totalni spokojenost ! jak ext4 tak JJ . boot ( grub - nacteni gnome ) na atomu pod 30s krasa

[MiBo]

Záleží jak moc věříte svému systému, Theodore Ts'o jeden z vývojářů  jádra tak nějak shrnul a že raději Ubuntu hráčům doporučil používat volbu nodelalloc při mountování ext4. (... I would recommend to Ubuntu gamers whose systems crash all the time and who want to use ext4, to use the nodelalloc mount option ...) Moc lichotivě se nevyjádřil o všech těch nestabilních proprietárních driverech v Ubuntu a jmenovitě tam vypíchnul Nvidiu, které stojí za následnými problémy ext4, když ten systém padá na natvrdo. Takže pokud se vám stane, že vám to sem tam spadne, tak raději ext3 nebo ext4 s nodealloc.

zdroj: http://thunk.org/tytso/blog/2009/03/12/delayed-allocation-and-the-zero-length-file-problem/

[Tadeáš Pařík]

Na ext4 přejdu až na podzim, kdy chci u Karmica udělat čistý instal a nebudu povyšovat. Na testovacích PC si s tím samozřejmě budu hrát dřív Ale noťas se snažím z "experimentů" vyloučit

[Pepe999]

Chtel jsem zkusit ext4 pri instalaci Sabayonu, predevcirem. Bohuzel je problem, instalacka mi pri zvolenem ext4(/) u formatovani odmita pokracovat s hlaskou, ze ext4 jeste neni plne funkcni(nebo se nedoporucuje, neco na ten zpusob) a minimalne /boot je treba udelat na neco klasickeho(ext3, reiserfs atd..), zbytek uz by zrejme nebyl problem na ext4 naformatovat. Nechal jsem tradicni reiserfs a funguje to taky...