Odpověď na názor

[40] Těžko si budou uživatelé FF stěžovat, že přišli o záložky, protože by se to mělo týkat jen věcí změněných bezprostředně před výpadkem. A je mi líto, pokud výpadek způsobí, že se poškodí již (kdysi dávno) uložená data, pak mi nepomůže ani fsync, protože... co když vypadne proud zrovna v půlce fsyncu? Žurnálovací FS nemusí nutně žurnálovat data. Já třeba všechny soubory ukládám stylem "ulož vedle a pak přejmenuj" a přejmenování se už žurnáluje po dokončení zápisu těch dat (takže buď se nic neuloží, nebo se uloží vedle, nebo se uloží správně, nic mezi tím).

120 commitů za sekundu je sakra málo. Ale opravdu sakra málo! Pokud těch 120 commitů nevyrobí jeden proces v jednom vlákně, tak bych si dokázal představit, že je bude OS groupovat a třeba jednomu procesu dovolí udělat 10 commitů za sekundu (1 fsync za 100ms) a pokud to přešvihne, pozdrží ho tak, aby se s tím svězl fsync z jiného procesu / threadu. Ono tím pozdržením lze řešit i situace, kdy je potřeba druhou stranu informovat, že zápis skutečně proběhl. Tohle by se dalo realizovat upravou výše představené knihovny (která by měřila čatnost sycnů a zdžovala by požadavky podle nastaveného plánu)

Jenže to neřeší dpkg, který tedy na jednu stranu přestane zvyšovat load operačního systému, ale jeho činnost se nijak nezrychlí.

pdflush a jeho řízení je kapitola samam pro sebe. Krásný je parametr dirty_ratio, které říká, že pokud dirty cache dosáhné této velikosti, veškeré IO se zablokuje, dokud se dirty cache neflushne na disk. Co to je za dementní pravidlo? Ať to spíš zablokuje tu aplikaci, dokud není HW dostatečně volný, aby mohl začít dirty stránky zapisovat na disk. Zase další způsob, jak sestřelit Linux DoS útokem pomoci aplikace spuštěné běžným uživatelem.

Čtení musí být prioritní,protože zatímco na čtená data někdo čeká, na zápis není třeba čekat, dokud někdo netrvá na syncu, případně pokud nedojde prostor v cache. A i tam to většinou je o jednom dvou kusech, zatímco na čtení může čekat stovky procesů.