Vlákno názorů k článku Výpadek TTC ochromil 200 tisíc e-mailových schránek Seznamu od Mikuláš Patočka - Při fsyncu se ostatní procesy nemusejí zastavovat. fsync je...

... a když to programátoři ze seznamu neumějí používat, tak jim to spadlo. Nesvaloval bych to na výpadek elektřiny, ups, filesystém, linux. Je to prostě tím, že ta mailová aplikace je špatně napsaná.

takhle jednoduchý to v plném pracovním vytížení zase není
pokud bych chtěl použít fsync tak musím zastavit procesy které manipulují s daty, jinak to nemá moc velký smysl.
to asi může rozkázat jenom božský Ivo (jenže tomu v tichomoří zrovna nešel satelitní telefon)
Pokud budete chtít deaktivovat některé služby určitě potřebujete povolení...

A že by aplikace při každé změně volala fsync no tomu snad nikdo nevěříme že ne? asi by moc rychlá nebyla

Prabvda pravdouci.

Navic fsync() nestaci, vetsinu kdyz uz, tak pouzivat fdatasync() a to vetsinou docela dost zpomaluje. Koneckoncu, fsync() by mel teoreticky nahradit zurnalovaci FS a ten tam maji nasazeny.

Nebyl bych tak útočný. Když si představím několik desítek vláken útočících na I/O scheduler, nebude žádná legrace to dát do kupy. RAID a podobný v tomhle případě nepomůže. Ono se to mluví...fsync. Ale:
1) databáze si zpravidla sama určuje, kdy bude zapisovat na disk a kdy ne. Ani transakce nepomůžou. Pomůže jen dobrá záloha :)
2) použití fsync() výrazně zpomalí celý systém. Chci vidět, toho člověka, který to bude používat na tyto aplikace.

Nehledě na množství dat, které tam protéká. Zeptej se na wz,
tak dlouho obnovovali rozbitý raid...

Nikdy neodhadneš míru poškození souborů. Samozřejmě například INNODB má něco jako žurnál, takže (snad) pozná, co je špatně. Já osobně bych měl taky strach při tomhle množství věcí něco pokoušet. Možná by bylo lepší (pokud by se na to přišlo včas) všechny servery včas vypnout. Ušetřila by se práce s obnovou. Ale po bitvě je každý kapitán...