Kiedy fsck jest niebezpieczny?

Ostatnio widziałem, jak główny system plików maszyny w zdalnym centrum danych został ponownie zamontowany w trybie tylko do odczytu, w wyniku problemów ze spójnością.

Podczas ponownego uruchamiania ten błąd był wyświetlany:

UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY (i.e., without -a or -p options)

Po uruchomieniu fsck zgodnie z sugestią i ręcznym zaakceptowaniu poprawek Ybłędy zostały skorygowane i system jest już w porządku.

Teraz myślę, że byłoby interesujące, gdyby fsck został skonfigurowany do automatycznego uruchamiania i naprawy wszystkiego, ponieważ jedyną alternatywą w niektórych przypadkach (jak ta) jest osobiste przejście do zdalnego centrum danych i podłączenie konsoli do komputera, którego dotyczy problem.

Moje pytanie brzmi: dlaczego fsck domyślnie prosi o ręczną interwencję? Jak i kiedy korekta wykonana przez taki program byłaby niebezpieczna? W jakich przypadkach administrator systemu może chcieć odłożyć na bok sugerowaną korektę (w celu wykonania innych operacji) lub całkowicie ją przerwać?

fsckzdecydowanie wyrządza więcej szkody niż pożytku, jeśli podstawowy sprzęt zostanie w jakiś sposób uszkodzony; zły procesor, zła pamięć RAM, konający dysk twardy, zepsuty kontroler dysku ... w takich przypadkach nieuniknione jest dalsze uszkodzenie.

W razie wątpliwości dobrym pomysłem jest zrobienie zdjęcia uszkodzonego dysku za pomocą dd_rescuelub innego narzędzia, a następnie sprawdzenie, czy uda się naprawić ten obraz. W ten sposób nadal masz dostęp do oryginalnej konfiguracji.

Widziałeś jeden przykład, w którym fsckdziałało, ale widziałem więcej niż wystarczająco uszkodzonych systemów plików, w których w ogóle nie działało pomyślnie. Jeśli zadziała w pełni automatycznie, możesz nie mieć szansy na zrobienie czegoś takiego jak ddzrzut dysku lub coś takiego, co w wielu przypadkach byłoby doskonałym pomysłem na zrobienie przed próbą naprawy.

To nigdy, przenigdy nie jest dobry pomysł, aby spróbować coś takiego automatycznego wcale.

Aha, a nowoczesne serwery powinny mieć zdalne konsole lub przynajmniej niezależne systemy ratunkowe, aby odzyskać z czegoś takiego bez konieczności podłączania szafy KVM do serwera.

Przede wszystkim musisz zrozumieć, że w nowoczesnych (dziennikowanych) systemach plików, awaria systemu nie uszkodzi systemu plików i podczas uruchamiania nie będzie wymagany fsck.

Ext3, Ext4, ZFS, btrfs, xfs i wszystkie współczesne FS są w 100% spójne po awarii lub resecie systemu.

Nieopublikowane FS, takie jak ext2 lub vfat, są dużym NOGO dla rootfów systemowych.

Teraz, jeśli twój system wymaga fsck podczas startu systemu, powinieneś zadać sobie pytanie: jaki był tego powód?

Powinieneś sprawdzić swoje dzienniki jądra, aby dowiedzieć się, kiedy i co się stało. Powinieneś również cofnąć się w czasie w dziennikach, aby znaleźć, odkąd błąd się zaczął. Powinieneś sprawdzić dyski za pomocą smartctl. Itd ... Jeśli potrzebujesz fsck na opublikowanym fs, jest praktycznie pewne, że twój sprzęt zawiedzie, zakładając, że fs nie został uszkodzony przez administratora (z narzędziami na poziomie bloku jak dd) lub przez błąd.

Dlatego niemądrze jest używać fsck do „naprawienia” problemu bez badania i naprawiania podstawowej przyczyny (poprzez wymianę / aktualizację wadliwego sprzętu / oprogramowania / oprogramowania).

Wykonanie fsck, ukończenie rozruchu i bycie szczęśliwym jest co najmniej naiwnością. Stwierdzenie „Miałem pracę fsck większą część czasu niż to, co zacytowałeś” powoduje, że zastanawiam się, co masz na myśli przez „fsck work”. fsck mógł przywrócić twój fs do spójnego stanu przez utratę niektórych plików i danych w tym procesie ... Czy porównałeś z kopią zapasową? Wiele osób traci pliki lub ulega uszkodzeniu, nie zauważając ...