W końcu spróbowałem tego, co sugerował womble; oto kilka innych szczegółów, które mogą być przydatne, jeśli, podobnie jak ja, nie widziałeś wcześniej tej nowej funkcji w e2fsck.
Opcja konfiguracyjna „scratch_files” dla e2fsck stała się dostępna w pewnym momencie w wersji 1.40.x. (W naszym przypadku musieliśmy zaktualizować system do najnowszej dystrybucji Debian, aby uzyskać tę funkcjonalność).
Oprócz zasugerowanej opcji „katalog = / var / cache / e2fsk”, istnieje kilka innych opcji konfiguracyjnych, które pozwalają precyzyjnie dostosować sposób przechowywania plików scratch. Użyłem „dirinfo = false”, ponieważ system plików miał dużą liczbę plików, ale nie tak dużą liczbę katalogów. Gdyby sytuacja uległa odwróceniu, odpowiednia byłaby opcja „icount”. Wszystkie te opcje zostały udokumentowane na stronie podręcznika e2fsck.conf.
BTW, Ted T'so napisał o tych opcjach w tym wątku .
Odkryłem, że e2fsck działał bardzo wolno, znacznie więcej niż przewidywał Ted. Przez większość czasu działał przy 99,9% obciążeniu procesora (na bardzo wolnym starym procesorze), co sugeruje, że przechowywanie tych struktur danych na dysku zamiast w pamięci nie było główną przyczyną spowolnienia. Możliwe, że coś innego w tym, co było przechowywane w systemie plików, sprawiło, że e2fsck jest szczególnie powolny. W końcu na razie porzuciłem sprawdzanie systemu plików; system plików miał zostać sprawdzony, ale nie miał błędów (o ile mi wiadomo), więc postaram się go sprawdzić w dogodniejszym czasie, kiedy będziemy mogli pozwolić sobie na tygodniową awarię.