Názor k článku Orchestrujeme pragmaticky: bez zbytečných nástrojů, s pomocí rsync od ventYl - FS *nema* veskere informacie o aktivite. Ma iba...

FS *nema* veskere informacie o aktivite. Ma iba tie informacie o aktivite, ktore mu niekto dorucil. Problem je v tom, ze sucastou tychto informacii nie je priznak, ci sucasny stav je "transakcne korektny". Napriklad ak aplikacia zapise 8MB blok do suboru, a tento zapis sa stihne flushnut niekam po FS, takze o nom FS vie a vie ho spracovat, FS nemoze vediet, ci k tomuto zapisu neprisluchaju nejake dalsie data, ktore napr. aplikacia prave pocita. A ak ich zapise, tak bude vysledny subor z pohladu aplikacie corrupnuty, pretoze nebude obsahovat data, ktore aplikacia prave pocita, ale aplikacia napr. musela flushnut data z predosleho vypoctu, aby mala dost prostriedkov na dalsie kolo vypoctov. Zaroven vsak prave zapisany blok prepisal informacie, ktore sa odkazovali na data, ktore este prepisane neboli.

Z pohladu FS je vsetko ok, pretoze predsa do snapshotu dal vsetko o com vedel, ze je on the fly. Z pohladu aplikacie su ale data odpad, pretoze cast dat zodpoveda starsej generacii informacie, nez zvysok. Vysledkom je corrupnuty subor bez ohladu na snahu.

Idea vsetko vkladat do DB (budem implicitne predpokladat transakcnu RDBMS) je jednoducho naivna. RDBMS (ale vo vseobecnosti akakolvek ACID capable databaza) je vhodna iba na limitovane mnozstvo use-caseov. Existuje mnoho pripadov, kedy ju mozne nie je pouzit bud z dovodu ohavnosti interface-u, alebo absolutne nevyhovujuceho vykonu.

TL;DR: Snazim sa len poukazat na to, ze fakt, ze snapshotovanie funguje na DB neznamena, ze je to vseliek. V skutocnosti je to skor vynimka, nez pravidlo.