Vlákno názorů ke zprávičce Ext4 pomohlo odhalit „špatně“ napsané aplikace

no tak si to radsi prectete jeste jednou, toto neni problem EXT4 ale spatne napsanych aplikaci, to same se Vam muze stat na vsech modernich FS s asynchronnim zapisem, staci se jen s vypadkem trefit do spravneho okamziku. "problem" EXT4 je, ze to okno pro "trefeni se" je velmi velke takze je narozdil od jinych FS vetsi pravdepodobnost, ze se to podari...

Bohužel při používání konfiguráků problém zřejmě nemá řešení. Může to být jen špatné, nebo ještě horší.

V pripade konfiguraku je reseni jednoduche - fsync(2). Dokonce tim ziskame lepsi stav nez predtim (uzivatel vzdy uvidi "novy" stav i po havarii, zatimco takhle nekdy videl az 5 vterin stary v pripade ext3). Problem je co s "malymi datovymi soubory" (typu cache browseru a podobne) - tam fsync(2) nechci delat, protoze me nezajima jestli uvidim stary nebo novy soubor, ale potrebuju jen garanci, ze kdyz uvidim nejaky, bude mit spravny obsah. Na coz je fsync() prilis silne.

-Yenya

Bohužel fsync() v řadě případů provede flush veškerých souborů otevřených na daném FS, což může trvat velmi dlouho. Navíc race condition nezmizí. Pořád se může stát, že smáznete starý konfigurák, ale už nestačíte přejmenovat ten dočasný na nový. Konfiguráky byly původně navrženy pro servery, které běžely měsíce bez zastavení, konfigurace se zapisovala prakticky výhradně ručně, a admin v bílém plášti a galoších znal všechny konfiguráky i jejich obsah. Podmínky se změnily, ale unixy bohužel ne.

fsync - synchronize a file’s in-core state with storage device

a file = jednoho souboru. Nevím o tom, že by to někdy dělal pro víc souborů (snad kromě sparse files, ale ty opravdu nejsou velké). Jediný možný problém je v tom, že fsync neflushne drive cache, tam je opravdu nutné flushnout všechno a zavolat sync.

Pořád se může stát, že smáznete starý konfigurák, ale už nestačíte přejmenovat ten dočasný na nový.

Houby, funkce rename je atomická.

fsync sice provede flush jednoho souboru, jenže řada FS (by default ext3) se snaží zapisovat data na disk v pořadí, ve kterém proběhly zápisy. Jinými slovy pokud vytvoříte A, přejmenujete B, a modifikujete C, tak fsync(C) vede k zapsání akcí provedených nad objekty A a B. A protože write cache může být plná různých věcí, a fsync je synchronní volání, tak vaše aplikace bude celkem dlouho čekat, než se dostane znovu k lizu.

Funkce rename je atomická, ale bohužel unlink(a);rename(b) atomické není. Ve Windows být může, ovšem to jsme vývojově o 10+ let jinde. U konfigurační DB, která tenhle problém nepotřebuje řešit, pak o 20+ let jinde.

Proč ten unlink? rename cíl přejmenování odstraní, pokud existuje, a to atomicky. A to uměl Unix už o 10+ let dříve, než Microsoft začal vyvíjet první Windows, tedy o 30+ let dříve, než tohle uměly i Windows.

Bohužel nejlepší možný stav je pořád mizený. fsync() trvá na některých FS velmi dlouho, přepisování konfiguráků kvůli změně jedné hodnoty je zbytečně dlouhé. Oni 10+ let před příchodem Windows měli implementovat konfigurační DB (a GUI, a tisk, a rozumné high level knihovny), a ne se prát o koryto a začínat unix wars ;)