На великих файлових системах не вистачає оперативної пам'яті

Я доглядаю за старим вікном Debian linux (працює etch) із лише 512 Мб оперативної пам’яті, але додається багато зовнішнього сховища. Одна файлова система ext3 має 2,7 ТБ, і fsck не може її перевірити, оскільки у неї не вистачає пам'яті, з такою помилкою:

   Помилка при розподілі блоку масиву каталогів: не вдалося розподілити пам'ять
   e2fsck: перервано

Я додав 4 ГБ своп-розділу, і він все ще не завершується, але це 32-бітове ядро, тому я не сподіваюся, що додавання більше допоможе.

Крім завантаження в 64-бітове ядро, чи існують інші способи отримання fsck для завершення його перевірки?

64-бітове ядро ​​та велика кількість оперативної пам’яті дозволять fsck закінчуватися красиво та швидко. Крім того, зараз в e2fsck є можливість, яка дозволить їй зберігати всі проміжні результати в каталозі, а не в оперативній пам'яті, що дуже допомагає. Створіть /etc/e2fsck.confіз наступним вмістом:

[scratch_files]
directory = /var/cache/e2fsck

(І, очевидно, переконайтеся, що каталог існує і знаходиться на розділі з кількома ГБ вільного місця). e2fsck запустить SLLOOOOWWWWWWW, але принаймні це буде завершено.

Звичайно, це не буде працювати з кореневим FS, але якщо у вас підміна, то ви все одно минуле монтуєте кореневий FS.

Я в кінцевому підсумку намагався зробити те, що запропонував живіт ось ще кілька деталей, які можуть бути корисні, якщо, як я, ви раніше не бачили цієї нової функціональності в e2fsck.

Опція конфігурації "scratch_files" для e2fsck стала доступною колись у періоді версії 1.40.x. (У нашому випадку нам довелося перейти до останнього дистрибутива Debian, щоб отримати цю функціональність.)

Окрім запропонованого варіанту "directory = / var / cache / e2fsk", є кілька додаткових параметрів конфігурації, щоб точно налаштувати, як використовується зберігання файлів подряпин. Я використовував "dirinfo = false", оскільки файлова система мала велику кількість файлів, але не таку велику кількість каталогів. Якби ситуація була зворотна, варіант "icount" був би доречним. Ці параметри були задокументовані на сторінці man для e2fsck.conf.

До речі, Тед Т'со написав про ці варіанти в цій темі .

Я виявив, що e2fsck працює дуже повільно, набагато більше, ніж передбачив Тед. Він працював на 99,9% використання процесора більшу частину часу (на надзвичайно повільному старому процесорі), що дозволяє припустити, що зберігання цих структур даних на диску замість пам'яті не було головною причиною сповільнення. Можливо, щось інше щодо того, що зберігалось у файловій системі, робило e2fsck особливо повільним. Зрештою, я покинув перевірку файлової системи; файлова система повинна була перевіритись, але не мала помилок (наскільки я знаю), тому я збираюся домовитись перевірити її у більш зручний час, коли ми можемо дозволити собі відключення на тиждень.