Aby fsck lub nie fsck po 180 dniach

Domyślnie po 180 dniach lub pewnej liczbie montowań większość systemów plików Linux wymusza sprawdzenie systemu plików (fsck). Oczywiście można to wyłączyć, używając na przykład tune2fs -c 0 -i 0 na ext2 lub ext3.

W małych systemach plików ta kontrola jest jedynie niedogodnością. Jednak w przypadku większych systemów plików sprawdzenie może zająć wiele godzin. Jeśli Twoi użytkownicy polegają na tym systemie plików pod względem produktywności, powiedzmy, że obsługuje on swoje katalogi domowe za pośrednictwem NFS, czy wyłącziłbyś zaplanowane sprawdzanie systemu plików?

Zadaję to pytanie, ponieważ jest obecnie 2:15 i czekam na bardzo długi fsck do ukończenia (ext3)!

Domyślny 180-dniowy czas fsck jest obejściem błędu projektowego polegającego na tym, że ext3 nie obsługuje sprawdzania spójności online. Prawdziwym rozwiązaniem jest znalezienie systemu plików, który to obsługuje. Nie wiem, czy ma to jakiś dojrzały system plików. To prawdziwa tragedia. Być może btrfs uratuje nas pewnego dnia.

Odpowiedziałem na problem niespodziewanego wielogodzinnego przestoju od fsck, wykonując zaplanowane restarty z pełnym fsck w ramach standardowej konserwacji. Jest to lepsze niż napotkanie drobnej korupcji w godzinach produkcji i sprawienie, by przerodziła się w prawdziwą awarię.

Dużą część problemu stanowi to, że ext3 ma niesłusznie wolny fsck. Chociaż xfs ma znacznie szybszy fsck, zużywa zbyt dużo pamięci dla dystrybucji, aby domyślnie zachęcać xfs do dużych systemów plików. Mimo to w większości systemów nie stanowi to problemu. Przejście na xfs pozwoliłoby przynajmniej na dość szybki fsck. Może to ułatwić zaplanowanie uruchomienia fsck w ramach normalnej konserwacji.

Jeśli korzystasz z RedHata i zastanawiasz się nad użyciem XFS, musisz uważać na to, jak silnie zniechęcają one do korzystania z XFS i fakt, że prawdopodobnie mało osób używa XFS na uruchomionym jądrze.

Rozumiem, że projekt ext4 ma na celu przynajmniej poprawę wydajności fsck.

Powiedziałbym, że jest to kolejny powód, dla którego serwery produkcyjne nie powinny działać całkowicie same i zawsze mają albo kopię zapasową na gorąco / na zimno, albo biorą udział w klastrze z dwoma węzłami. W dzisiejszych czasach wirtualizacji możesz z łatwością mieć fizyczny serwer główny i serwer wirtualny, który jest tylko kopią fizyczną wykonywaną co X dni, gotową do przejęcia.

Poza tym nie tak pomocna odpowiedź, powiedziałbym, że powinieneś zrównoważyć ważność swoich danych ... Jeśli jest to tylko węzeł klastra, pomiń go. Jeśli jest to nieskopiowany serwer internetowy klienta, możesz chcieć zaplanować następnym razem :-)

Zależy .. Na przykład jeden serwer przestał działać z powodu rutynowej konserwacji, na której działał stos QMail. QMail tworzy i zabija wiele plików w miarę upływu czasu, a to był bardzo zajęty serwer pocztowy. Fsck zajął około 36 godzin. Nie chodzi o to, że zaoszczędziliśmy sporo pieniędzy na transakcji, ale ostatecznie sądzę, że można argumentować, że system plików był zdrowszy. Czy to naprawdę było warte chaosu, który się pojawił? Nie. W. Wszystko.

XFS jest interesujący. Jest to zawsze spójny FS. Nie potrzebuje fsck. Nie spowoduje przestoju z powodu fsck.

Ale ma inny problem. Potrzebujesz kontrolera RAID z obsługą radzenia sobie z uszkodzonymi blokami dysku twardego.

XFS nie ma funkcji umieszczania na czarnej liście uszkodzonych bloków, gdy system operacyjny zaczyna wiedzieć o uszkodzonych blokach, a lista wadliwych bloków sprzętowych dysku twardego jest pełna.

ext2 / 3/4, fat, ntfs itp. (test offline) mogą umieszczać na czarnej liście uszkodzone bloki, ale nie XFS.

Dlatego w przypadku instalacji innych niż korporacyjne XFS prawdopodobnie nie pasuje dobrze. Korzystam z XFS z oprogramowaniem linux raid1 do tworzenia kopii zapasowych partycji, na których zawartość zawiera wiele małych plików bez większych zmian w czasie.