Řešení 1:
64bitové jádro a velké množství paměti RAM umožní fsck dokončit pěkně a rychle. Alternativně je nyní v e2fsck možnost, která mu řekne, aby uložil všechny své mezivýsledky do adresáře místo do RAM, což nesmírně pomáhá. Vytvořte /etc/e2fsck.conf s následujícím obsahem:
[scratch_files]
directory = /var/cache/e2fsck
(A samozřejmě se ujistěte, že adresář existuje a je na oddílu s dobrými pár GB volného místa). e2fsck spustí SLLOOOOWWWWWW, ale alespoň se dokončí.
Samozřejmě, že to nebude fungovat s kořenovým FS, ale pokud máte swap, pak jste stejně připojovali kořenový FS.
Řešení 2:
Nakonec jsem zkusil to, co navrhoval womble; zde jsou některé další podrobnosti, které mohou být užitečné, pokud jste jako já tuto novou funkci v e2fsck ještě neviděli.
Možnost konfigurace "scratch_files" pro e2fsck byla k dispozici někdy v období verze 1.40.x. (V našem případě jsme pro získání této funkce museli upgradovat na nejnovější distribuci Debianu.)
Kromě možnosti "directory =/var/cache/e2fsk", která byla navržena, existují některé další možnosti konfigurace pro jemné doladění způsobu použití úložiště odkládacích souborů. Použil jsem "dirinfo =false", protože souborový systém měl velký počet souborů, ale ne tak velký počet adresářů. Pokud by se situace obrátila, byla by vhodná možnost „icount“. Všechny tyto volby byly zdokumentovány v manuálové stránce pro e2fsck.conf.
BTW, Ted T'so psal o těchto možnostech v tomto vlákně.
Zjistil jsem, že e2fsck běží extrémně pomalu, mnohem více, než Ted předpovídal. Většinu času běžel na 99,9% využití CPU (na extrémně pomalém starém procesoru), což naznačuje, že ukládání těchto datových struktur na disk místo do paměti nebylo hlavní příčinou zpomalení. Je možné, že něco jiného na tom, co bylo uloženo v souborovém systému, způsobilo, že e2fsck byl obzvláště pomalý. Nakonec jsem kontrolu souborového systému prozatím opustil; souborový systém měl být zkontrolován, ale neměl chyby (pokud vím), takže zařídím jeho kontrolu ve vhodnější dobu, až si budeme moci dovolit týdenní výpadek.