Я хочу восстановить файловую систему ext2 на внешнем накопителе SD на 16 ГБ.
Когда я запускаю следующую команду:
e2fsck -y /dev/xxx
в моей системе не хватает памяти (Fedora 17 x64 8GB RAM, 8GB Swap).
Как было предложено в другом месте, Я добавил:
[scratch_files]
directory = /var/cache/e2fsck # (this directory exists and is writable to all)
кому:
/etc/e2fsck.conf
К сожалению, это исправление не работает. e2fsck использует каталог / var / cache / e2fsck, но все равно не хватает памяти.
Когда я запускаю команду в интерактивном режиме, она останавливается в следующем приглашении:
Inode 758 has an invalid extent
(logical block 0, invalid physical block 140737488469058, len 1)
Clear<y>? yes
Inode 758, i_blocks is 8, should be 0. Fix<y>?
Ответ «да» или «нет» на это приглашение дает тот же результат: оперативная память, используемая e2fsck, внезапно увеличивается до 8 ГБ +, и моя система зависает.
РЕДАКТИРОВАТЬ: в VirtualBox
Я попробовал fsck в VirtualBox с колоссальным пространством подкачки 40 ГБ. Fsck использовал все 4 ГБ ОЗУ и около 30 ГБ подкачки, затем он умер со следующим сообщением об ошибке:
Error storing directory block information (inode=759, block=0, num=295645313):
Memory allocation failed
Я решил эту проблему, создав файл подкачки на внешнем диске. Я создал 12-гигабайтный своп, чтобы дополнить существующий своп. Это позволило fsck без проблем завершить работу на файловом сервере 12 ТБ .. это определенно замедлило работу проверки диска. тем не мение.
Этот сайт документирует шаги: http://www.cyberciti.biz/faq/linux-add-a-swap-file-howto/
Скачок памяти звучит как e2fsck ошибка. В этом случае проблема может быть решена путем обработки этого индексного дескриптора вручную (с помощью debugfs; Я недостаточно знаком, чтобы объяснить, как это сделать).
Если это не ошибка и e2fsck просто нужно больше памяти, тогда есть «решение», которое не требует добавления ОЗУ, но определенно «переопределяет производительность» ... Проблема в том, что e2fsck не использует память подкачки как эквивалент. По крайней мере, так было в аналогичном случае. Заполняется ли ваше пространство подкачки полностью перед e2fsck вылетает? Возможно нет.
Ты можешь обмануть e2fsck принять своп как реальную оперативную память: вы можете загрузить второй Linux на виртуальной машине и экспортировать блочное устройство для проверки на виртуальную машину. Вы настраиваете виртуальную машину с большим объемом памяти, чем доступно физически. e2fsck в ВМ увидите больше ОЗУ. Конечно, это не делает ненужным использование scratch_files.
У меня были проблемы с запуском виртуальной машины с выделенной памятью больше, чем было доступно физической (!) ОЗУ, но согласно документации Fedora предполагается, что это возможно (возможно, это была даже не проблема KVM / QEMU, а какой-то причудливый материал ядра).