Życzę wszystkim udanego weekendu! Zapraszamy na bezpłatną lekcję Demo , którą poprowadzi Andriej Buranow — specjalista systemów UNIX w firmie Mail.Ru Group. Publikujemy również artykuł Jonathana Corbeta — redaktora naczelnego w LWN.net.
Systemy plików z dziennikiem obiecują uwolnić administratorów systemów od problemów związanych z uszkodzeniem dysku w przypadku awarii systemu. Nawet bez uruchamiania sprawdzania integralności systemu plików. Chociaż w rzeczywistości wszystko jest nieco bardziej skomplikowane. Ostatnia dyskusja pokazuje, że może być nawet bardziej zawiłe, niż wielu z nas myśli, ponieważ zapewnienie integralności systemów plików z dziennikiem wpływa na wydajność.
System plików, taki jak ext3, wykorzystuje osobny obszar na dysku, zwany dziennikiem. Przy wprowadzaniu zmian w metadanych systemu plików, te zmiany są najpierw zapisywane w dzienniku, nie modyfikując pozostałej części systemu plików. Po zapisaniu wszystkich zmian w dzienniku, dodawany jest „blok zatwierdzający”, wskazujący na zakończenie transakcji. Dopiero po zapisaniu bloku zatwierdzającego, transakcja zostaje zrealizowana, a zmienione metadane zapisywane są na dysku. Jeśli system w jakimś momencie ulegnie awarii, to za pomocą informacji w dzienniku można bezpiecznie zakończyć działanie i uniknąć uszkodzenia systemu plików z powodu aktualizacji tylko części metadanych.
Jednak jest jedno zastrzeżenie: kod systemu plików przed zapisaniem bloku zatwierdzającego musi być całkowicie pewny, że wszystkie informacje o transakcji zostały już przeniesione do dziennika. Po prostu zapisywanie operacji w odpowiedniej kolejności nie wystarczy — nowoczesne dyski wspierają dużą pamięć podręczną i reorganizują operacje dla poprawy wydajności. Dlatego przed blokiem zatwierdzającym należy wyraźnie wskazać na przeniesienie wszystkich danych dziennika na dysk. Jeśli blok zatwierdzający zostanie zapisany wcześniej, dziennik może zostać uszkodzony. Do rozwiązania tego problemu stosuje się bariery. W zasadzie bariera zabrania zapisu jakichkolwiek bloków po jej ustanowieniu, dopóki wszystkie bloki zapisane przed barierą nie zostaną przeniesione na dysk. Dzięki zastosowaniu barier, systemy plików zapewniają spójność struktur plików.
Ale jest jeszcze jeden problem: systemy plików ext3 i ext4 domyślnie nie używają barier. Opcja jest dostępna, ale jeśli administrator nie włączy ich wyraźnie, te systemy plików działają bez barier, chociaż w niektórych dystrybucjach (na przykład SUSE) domyślne ustawienia są inne. Eric Sandeen niedawno postanowił, że tę sytuację należy zmienić i , która modyfikuje domyślne ustawienia dla ext3 i ext4. I wtedy zaczęła się burzliwa dyskusja.
Andrew Morton bardzo szczegółowo , dlaczego domyślna wartość jest właśnie taka:
Ostatnim razem, gdy próbowaliśmy to zmienić, wydajność w wielu obciążeniach spadła o 30%, więc przerażony wyrzuciłem wszystkie te łatki. Myślę, że nie możemy sobie na to pozwolić i spowolnić wszystkie maszyny w tak poważny sposób…
Nie ma idealnych rozwiązań, i skłaniam się ku temu, aby nie budzić tego śpiącego psa i zostawić parametry domyślne do decyzji twórców dystrybucji.
W związku z tym, domyślnie bariery są wyłączone, ponieważ mają poważny wpływ na wydajność. Ponadto, systemy plików są całkiem skutecznie używane bez barier. Doniesienia o uszkodzeniu systemu plików ext3 są nieliczne i rzadkie.
Ale to nie tylko szczęście. Ted Ts’o to tym, że dziennik ext3 / ext4 jest zazwyczaj umieszczony w sposób ciągły. Po pierwsze, sterownik systemu plików stara się uczynić go ciągłym. Po drugie, dziennik zazwyczaj jest tworzony jednocześnie z systemem plików, kiedy łatwo znaleźć ciągłą przestrzeń. Ciągłość i porządek są korzystne nie tylko dla wydajności, ale także dla zapobiegania przestawianiu. Zazwyczaj blok zatwierdzenia będzie umieszczany tuż po innych danych w dzienniku, więc dysk nie ma powodów do przestawiania. Blok zatwierdzenia naturalnie jest zapisywany na dysku tuż po innych wpisach dziennika.
Niemniej jednak nikt nie twierdzi, że tak będzie zawsze. Nośniki danych mogą zachowywać się inaczej. Ponadto dziennik jest buforem cyklicznym. Dlatego, gdy transakcja jest zapisywana na końcu dziennika, blok commit może znajdować się wcześniej, przed innymi wpisami w dzienniku. Tak więc ryzyko uszkodzenia istnieje zawsze. W rzeczywistości Chris Mason ma dla tego . Nie ma wątpliwości, że praca bez barier jest mniej bezpieczna niż z nimi.
Jeśli jesteś gotów na spadek wydajności, możesz włączyć bariery. Oczywiście, jeśli twój system plików nie opiera się na LVM (jak w niektórych dystrybucjach domyślnie). Okazuje się, że mapowanie urządzeń nie obsługuje barier. W innych przypadkach warto byłoby zredukować spadek wydajności. I wygląda na to, że można to zrobić.
Aktualna implementacja ext3 (kiedy bariery są włączone) wykonuje następującą sekwencję operacji dla każdej transakcji:
Dane są zapisywane w dzienniku
Wykonywana jest bariera
Zapisany zostaje blok commit
Wykonywana jest następna bariera
Później metadane są zapisywane na dysk
W ext4 pierwszą barierę (krok 2) można pominąć, ponieważ system plików ext4 obsługuje sumy kontrolne w dzienniku.
Jeśli dane dziennika i blok commit są uporządkowane w inny sposób, a operacja przerwana na skutek awarii, suma kontrolna dziennika nie będzie odpowiadać tej, która jest przechowywana w bloku commit, a transakcja zostanie odrzucona.
Chris Mason , że "ogólnie rzecz biorąc" bezpieczniej byłoby usunąć tę barierę również w ext3, z możliwym wyjątkiem, gdy dziennik dociera do końca i zaczyna pisać od nowa.
Kolejny pomysł na przyspieszenie pracy - odkładanie operacji związanych z barierami, gdy to możliwe. Jeśli nie ma pilnej potrzeby natychmiastowego zapisywania danych na dysk, można utworzyć kilka transakcji w dzienniku i zrzucić je na dysk jednym barierą.
Jest również pewien potencjał do poprawy poprzez staranne uporządkowanie operacji, aby bariery (które zazwyczaj są realizowane jako żądania "zrzucić wszystkie opóźnione operacje na dysk") nie zmuszały do zapisu bloków, które nie wymagają uporządkowania.
Wygląda na to, że nadszedł czas, aby pomyśleć, jak uczynić koszt barier akceptowalnym. Ted Ts'o wydaje się :
Myślę, że powinniśmy włączyć bariery w ext3/ext4, a następnie pracować nad zmniejszeniem narzutów w ext4/jbd2. Prawdopodobnie zdecydowana większość systemów nie działa w warunkach podobnych do tych, które użył Chris do pokazania problemu, a bezpieczeństwo systemu plików powinno być priorytetem.
Rozsądek podpowiada mi, że ten pies już nie śpi i prawdopodobnie przez jakiś czas będzie szczekał. Może to wzbudzić niepokój niektórych sąsiadów, ale lepiej to niż pozwolić mu ugryźć.
Czy interesuje Cię rozwój w tym kierunku? Zapisy na bezpłatną lekcję demonstracyjną i weź udział w transmisji , którą poprowadzi Paweł Wikiryuk — operator komunikacji MVNO, inżynier DevOps.
Źródło: habr.com
