Miałem ostatnio dziwną przygodę: pewien serwer do backupu gdzie ląduje dużo małych plików i dodatkowo tworzonych jest sporo hardlinków zaliczył pada. Co prawda starałem się go grzecznie położyć z pomocą Magic SysRq ale ponieważ nie wiedziałem co było przyczyną awarii fsck wydawał się wskazany.
Podczas próby uruchomienia fsck.ext4 na systemie plików o rozmiarze ok 14TB z kilkuset milionami plików po kilkudziesięciu sekundach otrzymywałem komunikat:
Błąd podczas przydzielania struktury icount: Memory allocation failed
Googlając dowiedziałem się że problem jest znany i występuje podczas sprawdzania bardzo dużych systemów plików z dużą ilością hardlinków. To akurat idealnie mój przypadek… Przeważnie zdarza się to na systemach 32 bitowych gdy fsck próbuje zaalokować powyżej 2GB pamięci. Jest to górny limit możliwej do wykorzystania przez pojedynczy proces pamięci dla architektury 32 bitowej - nie można go przeskoczyć nawet stosując PAE. Ale mój system jest 64 bitowy, 8GB RAM’u, 8GB swap’a - nie jest dobrze jeśli brakuje pamięci ;-/
Zgodnie z sugestiami Teo Tso by zmniejszyć zapotrzebowanie fsck na pamięć można zmusić go by informacje o inodach i właściwościach katalogów przechowywał w tymczasowym katalogu. By wskazać katalog tymczasowy należy utworzyć plik: /etc/e2fsck.conf z zawartością:
[scratch_files]
directory = /var/cache/e2fsck
Katalog trzeba utworzyć ręcznie:
mkdir /var/cache/e2fsck
Warto zadbać o kilka/kilkanaście gigabajtów wolnego miejsca w tym katalogu - a najlepiej na czas sprawdzania podmontować jakiś zasób z fizycznie innego dysku niż sprawdzany. Ja wykorzystałem w tym celu kilku gigabajtowego pen drive’a.
Teraz można odpalić fsck’a (odpalając zdalnie warto zrobić to w screen’ie):
fsck.ext4 -f -C0 /dev/md1
Parametr -f wymusi sprawdzenie, a -C0 wyświetli pasek postępu co przy długim sprawdzeniu da nam jakieś wyobrażenie postępu. Tak uruchomiony fsck działa zdecydowanie wolniej niż przy domyślnych ustawieniach ale przynajmniej powinien się wykonać.
# fsck.ext4 -fD -C0 /dev/md1
e2fsck 1.41.12 (17-May-2010)
Przebieg 1: Sprawdzanie i-węzłów, bloków i rozmiarów
/dev/md1: |=========== | 19.4%
Opis podobnego problemu ze wsparciem Teo Tso: http://www.linux-archive.org/ext3-users/103464-2gb-memory-limit-running-fsck-6tb-device.html