Odpověď na názor

[39]

Prioritizace IO operací v jádře již nějaký ten pátek je. To co popisujete s pdflush je spíše na optimalizaci schedulerů, na čemž se, nepřekvapivě, též kontinuálně pracuje.

Ad hacky aplikací, zpožděný zápis apod. Však ta app má všechny prostředky, co k tomu potřebuje. Může si vynutit fsync hned, může to nechat na OS, může afaik vynutit pořadí pomocí barier (zde si nejsem jist, jestli to není jen VFS a userspace se k tomu nedostane). A pokud si potřebuje řídit, tak na to může mít spešl thread pro asynchronní (není-li nutný synchronní) zápis dat z hlavního vlákna a uživatelské prostředí nemusí na nic čekat. Všechno jde. App, které to ojebávají jinak (než je dokumentovaná vlastnost) jsou vadné. Tuhle jsem se díval na možnost běhu DB na NFS. V dokumentaci DB bylo, že pro NFS žádné spešl věci nedělají a nejsou třeba, protože to NFS se má chovat jako kterýkoliv jiný FS (a taky se tak chová, pokud si to někdo nenastaví podle Štraucha).

Ad hloupý FF. Kdyby to nedělal, tak si zase budou uživatelé stěžovat, že po crashi (výpadku proudu) přišli o záložky a zapamatovaná hesla. Zkrátka něco za něco.

Ad obava. Obavu nesdílím, někdy je prioritní čtení, jindy zápis. Já dělám DB. Tam se dá také lecos ojebat. A řeknu vám, že je daleko lepší se smířit (ono totiž ani nic jiného nezbyde), že klasický 7200rpm disk nedá víc jak 120 fsync (commitů) za sekundu. Můžu si hrát na to, že to není pravda a vypnout sync na disk, můžu to různě ojebat. Potom se to vymstí. Je daleko lepší vnímat realitu. Pokud 120 transakcí(zápi­sových) nestačí, musím koupit sas disky. Nebo serverové SSD. Nebo řadič s pořádně velkou write cache a baterkou. A nebo víte co? Použít jiný produkt. key-value in memory také existují a mají miliony operací za sekundu. K disposici mi to je.