Я присматриваю за старым Linux-сервером Debian (работающим под управлением etch) с 512 МБ ОЗУ, но с большим количеством подключенных внешних хранилищ. Одна файловая система ext3 имеет размер 2,7 ТБ, и fsck не может ее проверить, потому что у нее заканчивается память, с такой ошибкой, как эта:
Error allocating directory block array: Memory allocation failed e2fsck: aborted
Я добавил раздел подкачки на 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» был бы уместен. Все эти параметры были задокументированы на странице руководства для e2fsck.conf.
Кстати, Тед Т'со писал об этих вариантах в эта тема.
Я обнаружил, что e2fsck работает очень медленно, намного больше, чем предсказывал Тед. Большую часть времени он работал с загрузкой ЦП на 99,9% (на очень медленном старом процессоре), что говорит о том, что хранение этих структур данных на диске, а не в памяти не было основной причиной замедления. Возможно, что-то еще в том, что хранится в файловой системе, сделало e2fsck особенно медленным. В конце концов, я отказался от проверки файловой системы; файловая система должна была пройти проверку, но не имела ошибок (насколько я знаю), поэтому я собираюсь организовать ее проверку в более удобное время, когда мы сможем позволить себе недельный простой.