Vlákno názorů k článku
Deset největších průšvihů v historii Linuxu (první část)

Pro mě je největším průserem patch do jádra po tzv. chybě ext4.

Krátce připomenu o co šlo: Někteří uživatelé Ubuntu (první masově rozšířené disto s ext4) s root oddílem na ext4 hlásili ztrátu dat po tvrdém pádu stroje.

V čem byl problém: Špatně napsané programy spoléhaly na nečekanou vlastnost ext3, která ale nebyla zamýšlena. Ext3 totiž defaultně commituje změny v žurnálu každých 5s. A žurnál má nastavený na ordered. Toto v konečném důsledku způsobí, že se každých 5s zapíší všechna změněná data.

Programy na toto nedokumentované chování ext3 (a pouze ext3 s commit=5,da­ta=ordered) spoléhaly a nezajistily si správné uložení dat (různá volání fsync, případně různé mody otevření souboru pro zápis).

Ext4 a jiné FS se takto nechovají. Data drží v cache co možná nejdéle a zápis odkládají. Tím dosahují vyšších výkonů a nižší externí fragmentace.

Tak a teď, co považuji za průser. Místo, aby si uživatelé uvědomili, že po tvrdém pádu stroje nemusí mít na disku vůbec nic, natož pak změny v souborech provedené několik sekund před pádem a místo toho, aby se opravili blbě napsané programy spoléhající na nikým nezaručenou vlastnost jednoho systému souborů, tak místo toho se udělá patch do jádra (které s tím nemá nic společného), a na základě heuristiky se odhaduje, která data ukládat a která nechat na delay. Větší nesystémovost jsem za posledních 6 let v linuxu nezažil.

K linuxu jsem přešel právě pro jeho systémovost. Věci se dělaly správně. Problém se řešil tam, kde byl. Dovede si někdo vůbec představit, že v roce 2001 někdo přijde za Linusem a řekne: „hele, mám tu program co ukládá data a po resetu ta data na disku nejsou, udělej s tím něco v jádře“ a Linus mu to odkýve?

Tohle se široce diskutovalo. Do jisté míry bych s tebou i souhlasil, ale nejsem tak kategorický.

OS prostě nemůže bojovat se všemi aplikacemi. Zpětná kompatibilita je důležitá pro vážné nasazení Linuxu. Občas je potřeba udržovat i nedokumentovanou vlastnost nebo dokonce i bugu :-(. Kruté, ale je to tak, Microsoft o tom ví své.

Druhá věc je, že volání fsync na ext3 bylo velmi pomalé, aplikace, která to důsledně dělala vlastně přišla o cachování a byla pomalá.

Takže ta záplata, která některá data (přejmenování souboru) zapíše rychleji není systémová, ale bohužel nutná.

Samozřejmě ty aplikace by se měly opravit, ale není reálné to udělat všude a hned.

Komentar obsahuje nekolik podstatnych chyb:

= zejmena problem nebyl v tom, ze se zapis neprovedl na disk, ale v tom, ze se zapisy provedly na disk v jinem poradi, nez v jakem je zadal program.

= reseni s fsync() je nechutny overkill – jednak pouziti fsync() zarucuje mnohem vic, nez co je treba (aplikace potrebuji, aby obe operace probehly v urcitem poradi, ale nepotrebuji cekat na to, nez probehnou). Jednak na ext3 fsync() syncuje cely filesystem, takze caste pouziti fsync v aplikacich je na zabiti.

= Kdo chvili sleduje LKML tak vi, ze vyvojari jsou pomerne pragmaticti a tvrzeni typu ‚sice realny hardware takhle nepracuje, ale podle specifikace by tomu tak byt melo‘ ci ‚tohle chovani je sice neuzitecne, ale je stale v souladu s POSIXem‘ nemaji valnou vahu.

= Filesystem by mel poskytovate rozumne predpoklady o svem chovani. Velke casti jadernych vyvojaru se ocekavane predpoklady zdaly rozumne. Koneckoncu bez nich (a bez pomaleho fsync()) ani problemova operace nejde provest korektne.

= Objevily se navrhy na opravdu systemove reseni, ktere by se libilo i me – zavedeni syscallu fbarrier(), ktere zaruci pouze to, ze diskove operace zadane po volani fbarrier() se neprovedou pred diskovymi operacemi zadanymi pred tim volanim fbarrier(). Ale je otazka, jestli ho nekdo implementuje.

Jednak na ext3 fsync() syncuje cely filesystem, takze caste pouziti fsync v aplikacich je na zabiti.

Presneji pouziti fsync() kvuli implementaci zurnalu casto vede k syncnuti celeho filesystemu.