Gdy tworzymy aplikację i kod zapisujący do pliku, zwykle traktujemy operację zapisu jako wykonaną gdy sterowanie w kodzie przejdzie do kolejnych instrukcji. Zazwyczaj to fałszywe poczucie bezpieczeństwa w niczym nie przeszkadza. Do czasu, gdy pojawi się sytuacja awaryjna: aplikacja, system operacyjny, dyski lub zasilanie padną.
Odkrywamy jednak operację typu (f)flush() i czujemy się lepiej, bufory mamy opróżnione. Bardzo miło, ale nasza sytuacja w razie awarii systemu nie jest wiele lepsza. Jedyne co osiągnęliśmy, to wypchnięcie danych z jednych buforów do drugich (OS). Dane nadal nie są utrwalone. Jeśli oprogramowanie zapisuje krytyczne dane, realizuje jakąś transakcję, to kiepsko to wygląda.
Aby je utrwalić na nośnikach, musimy sięgnąć po fsync(). Bardzo ładnie jest to wyjaśnione tutaj.
Oczywiście, one nadal nie muszą być utrwalone. Jest jeszcze sterownik systemu plików, sterownik urządzenia blokowego, bufor w macierzy/kontrolerze dysków i w samym dysku! Ale jeśli sterowniki, kontroler dysków i firmware dysku są OK, no to w końcu czujemy się lepiej. Problem w tym, że nie zawsze są OK.
Poza tym, nawet jeśli są OK, awaria dysku/zasilania może przyjść w trakcie zapisywania danych na dysk i zapiszą się tylko częściowo i nie w tej kolejności, w której były zlecone. Implikacje mogą być bardzo daleko idące i dotyczą głównie implementacji: systemów plików, baz danych, systemów transakcyjnych, systemów kolejkowych czy nawet serwera pocztowego. Na pewno wszędzie, gdzie liczy się ACID.
Niektóre systemy udostępniają dodatkowe możliwość wpłynięcia na proces utrwalania, np. Mac OS X udostępnia w fnctl() opcję F_FULLFSYNC. Również Windows udostępnia funkcję FlushFileBuffers() do czyszczenia (całego) cache dysku oraz tryb otwarcia pliku FILE_FLAG_WRITE_THROUGH, których opis sugeruje, że załatwiają sprawę (głowy nie dam, ale wg tego porównania wypada nieźle).
Istnieją narzędzia, które świadomie korzystają z tego dobrodziejstwa, np.:
- SQLite (trop)
- patch do Erlanga (uwzględnione) przysłany przez CouchDB
- ActiveMQ (kod)
- H2 DB udostępnia, ale domyślnie świadomie rezygnuje (analiza)
Istnieją ponadto techniki radzenia sobie z częściowym utrwaleniem danych na podsystemie dyskowym w aplikacjach, które przepisują daną "w miejscu". Dla przykładu Websphere MQ zapisuje dziennik operacji (journal) w stronach i może się zdarzyć, że strona nie jest pełna. Wówczas zapisywana jest część strony, a reszta zostaje dopisana później. Ta druga operacja potencjalnie może skutkować utratą danych tego pierwszego zapisu. Aby to obejść, Websphere MQ domyślnie stosuje dla loga operacji metodę zapisu (LogWriteIntegrity) TripleWrite. Powoduje to dla niepełnych stron loga zapis pierwszej "połówki", na kolejnej stronie commit drugiej "połówki", a następnie (trzeci zapis) commit obu połówek razem do tej pierwszej strony.
To na ostateczne popsucie humoru:
- znacie programistów krytycznych aplikacji biznesowych ;) w Java, którzy świadomie robią coś więcej niż flush() by utrwalić dane?
- znacie kogoś, kto ma transakcyjną bazę danych SQL lub serwer SMTP na "oszukujących" dyskach SATA? (co lepsze, te low-endowe dyski mają duże 16-64MB cache)
- co się stanie z e-mailem, gdy serwer SMTP potwierdzi jego przyjęcie i nie zrobi fsync() na pliku w spoolu, po czym padnie zasilanie?
- znacie administratorów Linux, którzy świadomie wyłączają write cache na dyskach? (czasami robią to za nich same kontrolery macierzowe)
- zastanawialiście się co czeka system plików w wirtualnej maszynie po padzie hosta, zwłaszcza gdy ów filesystem gościa jest plikiem na systemie hosta? (hint)
- czy Wasz system plików księguje (journalling) dane, czy tylko metadane?
- ile lat temu pojawiło się wsparcie dla wiarygodnego utrwalania danych w Twoich krytycznych aplikacjach i systemach?
