Życzę wszystkim miłego weekendu! Zapraszamy na bezpłatną lekcję pokazową , które poprowadzi Andrey Buranov, specjalista ds. systemów UNIX w Grupie Mail.Ru. Na LWN.net publikujemy także artykuł Jonathana Corbeta – redaktora naczelnego.
Kronikowane systemy plików obiecują uwolnić administratorów systemu od kłopotów związanych z uszkodzeniem dysku w przypadku awarii systemu. Nawet bez sprawdzania integralności systemu plików. Chociaż w rzeczywistości wszystko jest oczywiście trochę bardziej skomplikowane. Jak sugeruje niedawna dyskusja, może to być jeszcze bardziej zagmatwane, niż wielu z nas sądzi, ponieważ zapewnienie integralności kronikowanych systemów plików ma wpływ na wydajność.
System plików taki jak ext3 wykorzystuje oddzielny obszar na dysku zwany dziennikiem. Kiedy wprowadzane są zmiany w metadanych systemu plików, zmiany te są najpierw zapisywane w dzienniku bez modyfikowania reszty systemu plików. Po zapisaniu wszystkich zmian w dzienniku do dziennika dodawany jest „blok zatwierdzania”, wskazujący zakończenie transakcji. I dopiero po zapisaniu bloku zatwierdzenia transakcja zostaje zatwierdzona, a zmienione metadane zapisane na dysku. Jeśli w pewnym momencie system ulegnie awarii, możesz wykorzystać informacje zawarte w dzienniku, aby bezpiecznie zamknąć system i uniknąć uszkodzenia systemu plików ze względu na fakt, że zaktualizowana została tylko część metadanych.
Jest jednak jeden haczyk: kod systemu plików musi mieć całkowitą pewność, że wszystkie informacje o transakcji zostały już zarejestrowane przed zapisaniem bloku zatwierdzenia. Samo rejestrowanie operacji we właściwej kolejności nie wystarczy — nowoczesne dyski obsługują duże wewnętrzne pamięci podręczne i zmieniają kolejność operacji w celu poprawy wydajności. Dlatego przed zatwierdzeniem bloku należy wyraźnie określić, że wszystkie dane dziennika są przesyłane na dysk. Jeśli blok zatwierdzenia został zapisany wcześniej, dziennik może być uszkodzony. Aby rozwiązać ten problem, stosuje się bariery. Zasadniczo bariera uniemożliwia zapisanie jakichkolwiek bloków zapisanych po barierze, dopóki wszystkie bloki zapisane przed barierą nie zostaną przeniesione na dysk. Stosując bariery, systemy plików zapewniają spójność struktur plików.
Ale jest inny problem: systemy plików ext3 i ext4 domyślnie nie używają barier. Istnieje taka opcja, ale jeśli administrator wyraźnie ich nie włączył, te systemy plików działają bez barier, chociaż niektóre dystrybucje (na przykład SUSE) mają inne ustawienia domyślne. Eric Sandeen niedawno zdecydował, że sytuacja ta wymaga zmiany i , który modyfikuje ustawienia domyślne dla ext3 i ext4. I wtedy zaczęła się gorąca dyskusja.
Andrew Morton (Andrew Morton) szczegółowo dlaczego wartość domyślna to:
Ostatnim razem, gdy próbowaliśmy to zmienić, wydajność przy wielu obciążeniach spadła o 30%, więc z przerażeniem wyrzuciłem wszystkie te poprawki. Nie sądzę, że możemy to zrobić i tak bardzo spowolnić wszystkie maszyny...
Nie ma tu rozwiązań idealnych i jestem skłonny nie budzić tego śpiącego psa i pozostawić domyślne opcje w gestii twórców dystrybucji.
Dlatego bariery są domyślnie wyłączone, ponieważ mają poważny wpływ na wydajność. Ponadto systemy plików można z powodzeniem stosować bez barier. Doniesienia o uszkodzeniu systemu plików ext3 są nieliczne.
Ale to nie tylko szczęście. Ted Ts'o dzieje się tak dlatego, że dziennik ext3/ext4 jest zwykle ciągły. Po pierwsze, sterownik systemu plików próbuje zapewnić ciągłość. Po drugie, dziennik jest zwykle tworzony w tym samym czasie co system plików, w którym łatwo jest znaleźć ciągłą przestrzeń. Ciągłość i porządek sprzyjają nie tylko produktywności, ale także zapobiegają ponownemu porządkowaniu. Zwykle blok zatwierdzenia zostanie umieszczony natychmiast po pozostałych danych w dzienniku, więc nie ma powodu do zmiany kolejności dysku. Blok zatwierdzenia jest naturalnie zapisywany na dysku natychmiast po pozostałych wpisach dziennika.
Nikt jednak nie twierdzi, że tak będzie zawsze. Napędy dyskowe mogą zachowywać się inaczej. Ponadto dziennik jest buforem pierścieniowym. Dlatego też, gdy transakcja jest zapisana na końcu dziennika, blok zatwierdzenia może znaleźć się we wcześniejszym bloku, przed innymi wpisami w dzienniku. Dlatego zawsze istnieje możliwość uszkodzenia. W rzeczywistości Chris Mason ma jeden do tego . Nie ulega wątpliwości, że praca bez barier jest mniej bezpieczna niż z nimi.
Jeśli chcesz przyjąć spadek wydajności, możesz włączyć bariery. Chyba, że Twój system plików jest oparty na LVM (tak jak domyślnie ma to miejsce w niektórych dystrybucjach). Okazuje się, że mapowanie urządzeń nie obsługuje barier. W innych przypadkach dobrym pomysłem byłoby ograniczenie degradacji wydajności. I wygląda na to, że da się to zrobić.
Obecna implementacja ext3 (gdy włączone są bariery) wykonuje następującą sekwencję operacji dla każdej transakcji:
Dane są rejestrowane
Bariera w trakcie realizacji
Zapisywany jest blok zatwierdzenia
Następna bariera zostaje pokonana
Później metadane są przesyłane na dysk
W ext4 pierwszą barierę (krok 2) można pominąć, ponieważ system plików ext4 obsługuje sumy kontrolne dziennika.
Jeśli kolejność danych dziennika i bloku zatwierdzenia zostanie zmieniona, a operacja się nie powiedzie, suma kontrolna dziennika nie będzie zgodna z sumą zapisaną w bloku zatwierdzenia, a transakcja zostanie odrzucona.
Chrisa Masona , że „ogólnie bezpieczne” byłoby usunięcie tej bariery w ext3, z możliwym wyjątkiem sytuacji, gdy dziennik dotrze do końca i zacznie być zapisywany od początku.
Innym pomysłem na przyspieszenie prac jest odłożenie operacji barierowych, gdy tylko jest to możliwe. Jeśli nie ma pilnej potrzeby natychmiastowego zrzucania danych na dysk, możesz utworzyć w logu kilka transakcji i zrzucić je na dysk za pomocą jednej bariery.
Istnieje również pewien potencjał ulepszeń poprzez ostrożne porządkowanie operacji, tak aby bariery (które są zwykle implementowane jako żądania „opróżnienia wszystkich oczekujących operacji na dysk”) nie wymuszały zapisu do bloków, które nie wymagają porządkowania.
Wygląda na to, że nadszedł czas, aby pomyśleć o tym, jak sprawić, by koszt barier był przystępny. Wygląda na to, że Ted Tso :
Myślę, że powinniśmy włączyć bariery w ext3/4, a następnie popracować nad zmniejszeniem obciążenia w ext4/jbd2. Jest prawdopodobne, że zdecydowana większość systemów nie działa w warunkach takich jak te, których Chris użył do zademonstrowania problemu, a bezpieczeństwo systemu plików powinno być domyślnie priorytetem.
Zdrowy rozsądek podpowiada mi, że ten pies już nie śpi i prawdopodobnie jeszcze przez chwilę będzie szczekał. Może to przeszkadzać niektórym sąsiadom, ale jest to lepsze niż pozwalanie jej gryźć.
Jesteś zainteresowany rozwojem w tym kierunku? Zapisz się na bezpłatną lekcję demonstracyjną i wziąć udział w transmisji , które poprowadzi Pavel Vikiryuk – operator telekomunikacyjny MVNO, inżynier DevOps.
Źródło: www.habr.com
