Jak długo można zapisywać w systemie plików w pamięci podręcznej z ext4?

Jakiś czas temu dyskutowano o tym, że ext4 potencjalnie pozostawia puste pliki po nieczystym odmontowaniu, podsumowane całkiem dobrze w tym artykule . Zasadniczo, z powodu opóźnionego przydziału, zapisy mogą być przechowywane w pamięci podręcznej zapisu przez znacznie dłuższy czas niż domyślny interwał zatwierdzania dziennika rozszerzenia (5 sekund).

Wydaje się, że problemy zostały naprawione w łatce, która wymusza blokowanie przydziału w określonych sytuacjach, tym samym zmuszając dane do dysku domyślnie po maksymalnie 5 sekundach.

Zastanawiam się, co się stanie, gdy aplikacja zastąpi istniejące części pliku, bez obcinania lub dołączania samego pliku. Czy to również zostanie zmuszone do dysku w ciągu 5 sekund?

Wydaje się, że jest to inna sytuacja niż dołączanie do pliku: podczas dołączania zmienia się rozmiar pliku, co jest zmianą metadanych; dlatego zatwierdzenie dziennika będzie konieczne w ciągu 5 sekund, a ze względu na dane = zamówione, dane będą musiały zostać wcześniej zapisane ze względów bezpieczeństwa (w przeciwnym razie części usuniętych plików innych użytkowników mogą pojawić się dla właściciela dołączonego plik).

Po prostu nadpisując dane pliku, nie ma powodu, dla którego zapis danych powinien nastąpić przed zatwierdzeniem dziennika metadanych, ponieważ stare dane należą do tego samego użytkownika co nowy. Czy więc zapis ma miejsce przed zatwierdzeniem, czy może być opóźniony dłużej niż interwał zatwierdzenia dziennika? Jeśli tak, to jak długo?

Aktualizacja: Wiem, że wszystko to jest nieistotne, gdy robisz właściwą rzecz, to znaczy używając fsync (). (To był główny powód całej dyskusji na temat ext4 i utraty danych - problem dotyczył tylko aplikacji, które nie były fsync () lub nie we właściwych momentach.) Nie piszę własnej aplikacji, pytam, ponieważ ja nie wiem, czy wszystkie moje aplikacje działają poprawnie, i chcę znać przybliżone ramy czasowe dla takich „niebezpiecznych” zapisów. Powodem pytania jest to, że mój sterownik grafiki regularnie powoduje panikę jądra i chcę wiedzieć, czy muszę się martwić o więcej niż ostatnie 5 sekund zapisu danych.

Można ustawić interwał zatwierdzania na niestandardową wartość, która, moim zdaniem, może być tak wysoka, jak 32-bitowa liczba całkowita bez znaku; czyli około 4 miliardów sekund lub 136 lat. Jest to dostępne poprzez commitopcję montowania, którą możesz zastosować w następujący sposób (jest to tylko przykład; możesz także ustawić to w fstab):

mount /dev/sda1 -t ext4 -o rw,data=writeback,nobh,commit=12345678

Interwał zatwierdzania nie jest oparty na żadnym rodzaju warunku, takim jak to, czy dane są dołączane, czy też zastępuje istniejące dane, czy cokolwiek innego. Opcja commitmontowania (która domyślnie wynosi 5 sekund, jeśli w ogóle nie podasz opcji montowania) jest odpowiednikiem wykonania czegoś takiego w powłoce bash:

#!/bin/bash
while :
do
    echo "Syncing all uncommitted data and journal to disk"
    sync
    sleep 5
done

Nie pomyl data=orderedtego, a ten globalny interwał synchronizacji systemu plików („przedział zatwierdzenia” jest być może mniej znaczącym terminem dla tych z nas, którzy rozumieją funkcjonalność programu wiersza poleceń sync, w którym to przypadku można go lepiej nazwać „interwał synchronizacji”). data=ordereddotyczy kolejności aktualizacji danych i metadanych (gdzie data=writebackjest „mniej bezpieczny / szybszy” i data=journal„bardziej bezpieczny / wolniejszy”). commit=12345678dotyczy częstotliwości, z jaką sam sterownik systemu plików wymusza PEŁNĄ synchronizację WSZYSTKICH brudnych danych / dziennika / metadanych / cokolwiek innego na nośniku fizycznym. Z pewnością możesz ustawić go na 136 lat, jeśli chcesz, i montować z data=writeback,nobhprogramami, które nie wywołują fsync()lub sync()będą mieć brudne strony w pamięci RAM przez ...

Aktualizacja: Na podstawie kontekstu w edycji pytania powiedziałbym, że powinieneś uruchomić swój system plików z opcjami montowania, data=journal,commit=1a nawet z syncopcją montowania, dopóki nie będziesz w stanie rozwiązać paniki sterownika karty graficznej. Pozwoli to zachować maksymalną integralność danych, ale kosztem wydajności. Będziesz szczególnie chciał to zrobić, jeśli często zapisujesz dane na dysku, na których utratę nie możesz sobie pozwolić, a to jest podwójnie ważne, jeśli nie ufasz aplikacjom, których używasz do fsync()odpowiedniego zastosowania .

Źródło: tutaj i osobiste doświadczenia

Jakakolwiek jest odpowiedź na twoje pytanie, nie ma to znaczenia.

Gwarantowana narażony zachowanie systemu plików ext4 jest, że „dane będą znajdować się na dysku po udanej sync/ fsyncrozmowy”. Tak więc, jeśli masz aplikację, która powoduje, że zadajesz to pytanie, powinieneś wstawiać wywołania synchronizacji w krytycznych punktach, w których należy zapewnić integralność danych. Jeśli martwisz się tym samym problemem, możesz zadzwonić do syncnarzędzia wiersza polecenia, zanim zrobisz coś niebezpiecznego, co może spowodować nieczyste zamknięcie.