Znaczenie fsck podczas rozruchu w systemach plików Journalled?

10

Zauważyłem, że XFS nie implementuje fsck podczas uruchamiania systemu, a jeden z powodów wymienionych w tym systemie plików kronikowania pomaga zapewnić spójność systemu plików po nieczystym zamknięciu; na następnym montażu (np. po ponownym uruchomieniu) dziennik jest odtwarzany.

Czy FSSck jest nadal potrzebny po nieczystym zamknięciu i dlaczego?


źródło

Odpowiedzi:

4

Odpowiadam na to w ogólnym kontekście „rejestrowanych systemów plików”.

Myślę, że jeśli nie kilka postojów „nieczystych” (przez ciągnięcie za przewód zasilający lub coś ) prędzej czy później można dostać się do stanu systemu plików, które wymagałyby fscklub moralny odpowiednik fsck, xfs_repair. ext4Fileystsm na moim laptopie w większości przypadków po prostu odtwarza dziennik na każdym restarcie, czyste postoje w cenie, ale raz na jakiś czas, to jednak w pełni na fsck.

Ale zadaj sobie pytanie, co osiąga „odtworzenie dziennika”. Ponowne odtworzenie dziennika tylko zapewnia, że ​​bloki dyskowe reszty systemu plików są zgodne z kolejnością wymaganą przez wpisy dziennika. Ponowne odtworzenie dziennika jest małe fscklub pełne fsck.

Wydaje mi się, że trwa słowna sztuczka: odtwarzanie dziennika jest częścią tego, co tradycyjne fsck, i xfs_repairjest dokładnie tym samym rodzajem programu, jakim jest e2fs.fsck(lub jakikolwiek inny system plików fsck). Ludzie XFS po prostu uwierzyli lub ich doświadczenie sprawiło, że nie uruchamiali się xfs_repairprzy każdym uruchomieniu, tylko odtwarzali dziennik.

Bruce Ediger
źródło
3
Z wyjątkiem błędu w kodzie kronikowania lub dysku, żadna liczba nieczystych wyłączeń nie może pozostawić dysku w stanie wymagającym fsck. ext [34] nadal zachowuje pedantyczny automatyczny fsck po tak wielu montowaniach częściowo jako przeniesienie z ext2 w połączeniu z, no cóż ... pedantyczną postawą „na wszelki wypadek”. Przynajmniej w najnowszych wersjach Ubuntu jest to domyślnie wyłączone.
psusi
Z mojego doświadczenia fsckwynika , że automatyka nie jest „pedantyczna”. Przekształciłem ext3 LVMpartycję ext4i zacząłem otrzymywać błędy „ext4_mb_generate_buddy” z powodu, jak rozumiem, błędu w ext4kodzie, który spowodował niedopasowanie kopii bitmapy na dysku i w pamięci na przekonwertowanych partycjach „LVM”. O ile wiem fsck, nie doszło do korupcji. Rozwiązaniem było albo wyłączenie UNINIT_BGopcji, albo przeniesienie danych i ponowne zainicjowanie partycji jako ext4; Wybrałem ten drugi kurs. Ale nadal uważam, że kilka minut oczekiwania na nie fsckjest warte utraty danych!
StarNamer,
1
W tej odpowiedzi jest wiele brakujących informacji, dlatego zagłosuj i odpowiedz inaczej.
symcbean
4

pomagają zapewnić spójność systemu plików po nieczystym zamknięciu

Pierwszą rzeczą godną uwagi jest to, że XFS, reiser i większość konfiguracji ext wdrażają tylko rejestrowanie metadanych, co polega na unikaniu fsck. Dziennik nie zawsze jest odtwarzany przy uruchamianiu - może zostać odrzucony, jeśli jest niekompletny.

Istnieją systemy, które obsługują pełną rejestrację danych - ale w praktyce poziom pewności, jaki dają one w przypadku rejestrowania tylko metadanych, jest bardzo niski w rzeczywistych scenariuszach.

Tak więc „niespójny stan” i problemy naprawione przez fsck, są rozbieżnościami między metadanymi i samymi plikami. Aby tego uniknąć, system operacyjny zapisuje proponowane zmiany metadanych w dzienniku, a następnie zapisuje rzeczywiste dane na dysku, a następnie stosuje zmiany metadanych, które są replikowane w dzienniku na dysk. Jedynym problemem jest to, że kontroler dysku buforuje i potencjalnie zmienia kolejność żądań. Aby tego uniknąć, większość systemów plików kronikowania implementuje bariery: oddzielają każdą operację i czekają, aż dysk potwierdzi, że operacja została zakończona. Ale wiele współczesnych dysków faktycznie potwierdza zakończenie zapisu przed zatwierdzeniem danych. W związku z tym sprawy mogą się popsuć.

Czy fsck jest nadal potrzebny po nieczystym zamknięciu i dlaczego?

Większość systemów plików utrzymuje liczbę podłączeń - po osiągnięciu tego licznika zostanie uruchomione pełne polecenie fsck przy kolejnej próbie zamontowania dysku. Powodem jest to, że dane na dysku mogą być uszkodzone, nawet jeśli nie są jawnie zapisywane, nawet bez błędów w oprogramowaniu. powyższy komentarz psusi jest błędny.

symcbean
źródło
Zamieszanie zamówień z barierami. Dyski nie zgłaszają zapisów jako zakończonych, zanim trafią na dysk, chyba że włączysz pamięć podręczną zapisu, która jest domyślnie wyłączona na dyskach na poziomie konsumenta, więc przy nich fs musi poczekać na zakończenie zapisu przed wydaniem następnego . W przypadku sprzętu z pamięcią podręczną zapisu stosowane są bariery zapobiegające zmianie kolejności i zmuszające dysk do opróżnienia pamięci podręcznej zapisu, zapobiegając w ten sposób uszkodzeniu fs.
psusi
1
psusi - co paliłeś? „Dyski nie zgłaszają zapisów jako zakończone przed ...” - tak, robią. „włącz pamięć podręczną zapisu, która jest domyślnie wyłączona” - nie na żadnym dysku, który kiedykolwiek skonfigurowałem. „stosowane są bariery, aby zapobiec zmianie kolejności” - ale powiedziałeś, że „mieszałem zamawianie z barierami”
symcbean
Nie, nie robią tego. Jeśli nie włączysz pamięci podręcznej zapisu na dysku ( hdparm -W), dysk nie zakończy żądań zapisu, dopóki nie znajdzie się na nośniku. Jak myślisz, dlaczego ta opcja istnieje? Bariery uniemożliwiają zmianę kolejności w przypadku wydania wielu żądań. Bez barier fs po prostu nie wysyła więcej żądań, dopóki poprzednie nie zostaną zakończone, utrzymując w ten sposób porządkowanie bez barier ... pod warunkiem, że pamięć podręczna zapisu dysku nie jest włączona. Celem barier jest umożliwienie włączenia pamięci podręcznej zapisu bez uszkadzania FS podczas awarii.
psusi
Ups, trochę się pomieszałem i zapomniałem sync. Pozwól mi spróbować jeszcze raz. Procedura zapisu na dysk bez barier polega na zapisaniu do dziennika sync, a więc opróżnieniu pamięci podręcznej zapisu, a następnie zapisaniu rzeczywistych danych. Dzięki temu dziennik zawsze może zostać użyty do odzyskania fs po awarii, ale synchronizacja spowalnia rzeczy, a połowa pokonuje cel pamięci podręcznej zapisu. W ten sposób bariery zostały dodane jako lepsze zamienniki sync, a przy odpowiedniej obsłudze dysków mogą bezpiecznie odzyskać znaczną część wydajności, którą zabiera synchronizacja.
psusi
2

Nie ma potrzeby fsck systemu plików kronikowania tylko z powodu nieczystego zamknięcia.

Cała przyczyna trwałej karę wydajność runtime księgowaniem metadanych jest zapewnienie, że system plików może być wykonana w 100% spójne ponownie automatycznie odtwarzanie dziennik metadanych na następny zamontować, jeśli system plików nie był czysto nieoprawione.

Jedyną rolą fsck jest zapewnienie spójności metadanych, więc uruchamianie fsck jest zbędne, ponieważ system plików nie został poprawnie odmontowany.

System plików kronikowania może ulec uszkodzeniu z innych powodów - awarii sprzętu, błędów sterownika, błędów administracyjnych itp. - więc narzędzia fsck są z pewnością niezbędne. Po prostu nie ma powodu, aby je wywoływać wyłącznie z powodu nieczystego zamknięcia.

Eric Sandeen
źródło
co z wywoływaniem ich przy każdym ponownym uruchomieniu? przydatny? lub po prostu poczekaj na zgłoszenie problemu, a następnie uruchom fsck?
simpleuser