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.
