Недостаточно памяти для запуска fsck на больших файловых системах

Я закончил тем, что попробовал то, что предложил womble; Вот еще некоторые подробности, которые могут быть полезны, если вы, как и я, ранее не видели этой новой функциональности в e2fsck.

Опция конфигурации "scratch_files" для e2fsck стала доступна когда-то в версии 1.40.x. (В нашем случае нам пришлось обновиться до последней версии Debian, чтобы получить эту функциональность.)

Наряду с предложенной опцией "directory = /var/cache/e2fsk" существуют некоторые дополнительные параметры конфигурации, позволяющие тонко настроить использование хранилища чистых файлов. Я использовал "dirinfo = false", поскольку файловая система имела большое количество файлов, но не такое большое количество каталогов. Если ситуация обратная, то подойдет вариант "icount". Все эти параметры описаны в справочной странице для e2fsck.conf.

Кстати, Тед Тсо написал об этих опциях в этой теме.

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

Лучше всего попробовать перейти на 64-битное ядро, если у вас очень большая файловая система. В некоторых случаях 32-битный e2fsck будет не хватать памяти даже с рабочими файлами (о том, как их использовать, см. ответ @womble или man e2fsck).

У меня была такая установка с файловой системой 11 ТиБ, которая используется в качестве цели резервного копирования - с множеством жестких ссылок - и я недавно обновил ее до 64-разрядной исключительно для того, чтобы иметь возможность запускать e2fsckбез возможности загрузки с внешнего носителя. Рассматриваемая машина - очень старая коробка, всего с 2 ГиБ ОЗУ, но у нее есть 64-битный процессор. ОС была 32-битной, потому что она просто обновлялась более десяти лет, но после увеличения резервной ФС до (я думаю) 5 ТиБ я больше не мог запускать на ней e2fsck, несмотря на то, что у меня был своп на 5 ГиБ и настройка e2fsck использовать рабочие файлы.

Однако после 64-битного обновления теперь кажется, что оно может быть завершено; по крайней мере, сейчас это сделано почти на 80% после 18 часов пробежки; раньше он никогда не мог приблизиться к этому состоянию. Мое лучшее предположение о том, почему он всегда будет терпеть неудачу в 32-битной системе, - это размеры самих временных файлов; в настоящее время размер одного из них превышает 3,3 ГиБ.

Конечно, если ЦП не имеет поддержки 64-битной системы, ситуация сложная, но почти все системы, поддерживающие достаточно большие физические диски, чтобы столкнуться с этой проблемой, вероятно, будут иметь ее.

EDIT: пример использования памяти указанным e2fsck процесс:

VmPeak: 10687568 kB
VmSize: 10687568 kB
VmLck:         0 kB
VmPin:         0 kB
VmHWM:   1706284 kB
VmRSS:    715104 kB
RssAnon:      417312 kB
RssFile:      297792 kB
RssShmem:          0 kB
VmData:  3151052 kB
VmStk:       132 kB
VmExe:       232 kB
VmLib:      1888 kB
VmPTE:      8676 kB
VmSwap:  1550760 kB

Как показано, процесс имеет колоссальное адресное пространство 10 ГиБ, хотя фактическое VmDataразмер остается в пределах 4 ГиБ системы с поддержкой PAE, поэтому у него не будет шансов на успешное завершение на 32-разрядной машине. Конечно, технически возможно, что 32-разрядная версия по-другому обрабатывает адресное пространство, но я бы не стал на это рассчитывать.