Назад | Перейти на главную страницу

Основные проблемы с fsck 10 ТБ ext3 RAID 6 (сбой выделения памяти и т. Д.)

Недавно я добавил 7-й диск емкостью 2 ТБ в конфигурацию RAID 6 программного обеспечения linux md. После того, как md закончил преобразование массива с 6 до 7 дисков (с 8 до 10 ТБ), я все еще смог без проблем смонтировать файловую систему. Готовясь к resize2fs, я размонтировал раздел и запустил fsck -Cfyv и был встречен бесконечным потоком миллионов случайных ошибок. Вот небольшой отрывок:

Pass 1: Checking inodes, blocks, and sizes
Inode 4193823 is too big.  Truncate? yes
Block #1 (748971705) causes symlink to be too big.  CLEARED.
Block #2 (1076864997) causes symlink to be too big.  CLEARED.
Block #3 (172764063) causes symlink to be too big.  CLEARED.
...
Inode 4271831 has a extra size (39949) which is invalid Fix? yes
Inode 4271831 is in use, but has dtime set.  Fix? yes
Inode 4271831 has imagic flag set.  Clear? yes
Inode 4271831 has a extra size (8723) which is invalid Fix? yes
Inode 4271831 has EXTENTS_FL flag set on filesystem without extents support. Clear? yes
...
Inode 4427371 has compression flag set on filesystem without compression support. Clear? yes
Inode 4427371 has a bad extended attribute block 1242363527.  Clear? yes
Inode 4427371 has INDEX_FL flag set but is not a directory. Clear HTree index? yes
Inode 4427371, i_size is 7582975773853056983, should be 0.  Fix? yes
...
Inode 4556567, i_blocks is 5120, should be 5184.  Fix? yes
Inode 4566900, i_blocks is 5160, should be 5200.  Fix? yes
...
Inode 5628285 has illegal block(s).  Clear? yes
Illegal block #0 (4216391480) in inode 5628285.  CLEARED.
Illegal block #1 (2738385218) in inode 5628285.  CLEARED.
Illegal block #2 (2576491528) in inode 5628285.  CLEARED.
...
Illegal indirect block (2281966716) in inode 5628285.  CLEARED.
Illegal double indirect block (2578476333) in inode 5628285.  CLEARED.
Illegal block #477119515 (3531691799) in inode 5628285.  CLEARED.

Сжатие? Экстенты? У меня на этой машине ext4 никогда не было!

Теперь проблема в том, что fsck продолжает умирать со следующим сообщением об ошибке:

Error storing directory block information (inode=5628285, block=0, num=316775570): Memory allocation failed

Сначала я мог просто повторно запустить fsck, и он умер на другом inode, но теперь он остановился на 5628285, и я не могу заставить его выйти за рамки этого.

Я потратил последние дни на поиски исправлений и нашел следующие 3 «решения»:

Излишне говорить: ничего не помогло, иначе я бы здесь не писал.

Естественно, теперь диск помечен как плохой, и я больше не могу его монтировать. Итак, на данный момент я потерял 8 ТБ данных из-за проверки диска?!?!?

Это оставляет мне 3 вопроса:

(Сейчас я использую e2fsck 1.42.5 на 64-битном Debian Wheezy 7.1, но у меня были те же проблемы с более ранней версией на 32-битном Debian Squeeze)

Просто перестройте массив и восстановите данные из резервной копии. Весь смысл RAID - минимизировать время простоя. Пытаясь решить такую ​​проблему, вы просто увеличиваете время простоя, сводя на нет всю цель RAID. RAID не защищает от потери данных, он защищает от простоев.

После игры с fsck еще немного, я нашла несколько средств:

Предотвращение ошибки "Ошибка выделения памяти"

fsck похоже, есть серьезная проблема с утечкой памяти. Если он запущен в файловой системе с некоторыми проблемами (реальными или мнимыми), он будет «исправлять» их одну за другой (см. Дамп экрана в исходном вопросе). При этом он потребляет все больше и больше памяти (может быть, ведёт журнал изменений?). Практически без ограничений. Но, fsck можно отменить в любой момент (Ctrl-C) и перезапустить. В этом случае он продолжится с того места, где остановился, но использование памяти сбрасывается почти до нуля (на некоторое время).

Имея это в виду, необходимо сделать три вещи:

  • Используйте 64-битный Linux (кажется, разница в том, как fsck может использовать доступную память)
  • Добавьте смехотворно огромный раздел подкачки (я использовал 256 ГБ, fsck работает с ним около 12 часов)
  • Часто прерывайте и перезапускайте fsck (частота зависит от размера раздела подкачки)

ПРИМЕЧАНИЕ: я понятия не имею, будет ли отмена и перезапуск fsck несет с собой любые другие опасности (вероятно, есть), но, похоже, для меня это работает.

Устранение возникшего ущерба, если возникает ошибка «Ошибка выделения памяти» (ВАЖНО!)

fsck обрабатывает Memory allocation failed ошибка наихудшим образом: я уничтожаю совершенно хорошие данные. Я не уверен, почему, но я предполагаю, что он выполняет окончательную запись данных на диск вещей, которые он хранил в памяти, которые (из-за ошибки) тем временем были повреждены.

В моем случае наиболее заметной проблемой было то, что при перезапуске fsck после ошибки иногда сообщалось о повреждении суперблока. Проблема в том, что я понятия не имею как поврежден суперблок, особенно в тех случаях, когда он не сообщал о повреждении. Возможно, при перезапуске после ошибки он затем использует неверные метаданные диска, обнаруженные в поврежденном суперблоке, для выполнения всех дальнейших проверок и в конечном итоге исправляет «проблемы», которых на самом деле нет, уничтожая хорошие данные в процессе.

Следовательно, если fsck Когда-либо умирает с Memory allocation failed ошибка, его необходимо перезапустить с помощью -b параметр для использования резервного суперблока, который (надеюсь) не был поврежден ошибкой. Расположение суперблоков резервного копирования можно найти с помощью mke2fs -n /dev/....

Поскольку я не знаю, что произойдет, если fsck умирает с выбранным резервным суперблоком, я обычно просто прерываю fsdk немедленно, когда доходит до Pass 1: Checking inodes, blocks, and sizes и перезапустите его снова без -b, после чего он запускается без жалоб на плохой суперблок. Т.е. это кажется первым делом fsck -b делает это для восстановления основного суперблока.

Теперь тот, которого мы все ждали:

Как смонтировать файловую систему, не дожидаясь завершения работы fsck

Это я обнаружил случайно: Оказывается, после запуска fsck -b и прервать его, как только он напечатает Pass 1: Checking inodes, blocks, and sizes (до того, как будут обнаружены какие-либо ошибки) файловая система остается в монтируемом состоянии (Ура! Я вернул почти все свои данные!).

(Примечание: может быть другой способ использования mount -o force, но в моем случае это было не нужно.)

Как избежать всех этих проблем в первую очередь

Кажется, есть два пути:

  • Используйте ext3, но держите резервную копию в актуальном состоянии. Затем часто запускайте fsck с параметром -N. Если это показывает любой проблемы удалите всю фс и восстановите все из бэкапа. Поскольку в этом сценарии можно очень сильно полагаться на резервную копию, я предлагаю сохранить резервную копию резервной копии. Кроме того, используйте инструмент копирования, который каким-то образом гарантирует, что восстановление не создаст случайных ошибок в процессе (MTBF в триллион оборотов / операций в секунду невелик при работе с ТБ данных). Обязательно спланируйте время простоя, так как восстановление нескольких ТБ, вероятно, займет некоторое время ...
  • Моя рекомендация: НЕ используйте ext3! Программа fs-design и связанные с ней инструменты (здесь fsck) недостаточно надежны для реального производственного использования (пока?). Способ fsck обрабатывает ошибку памяти, и тот факт, что ошибка возникает в первую очередь, на мой взгляд, неприемлем. С этого момента я буду пробовать xfs, но пока у меня недостаточно опыта, чтобы сказать, лучше ли это.

К сожалению, я не могу «добавить комментарий», но мне пришлось вмешаться и поблагодарить Op. У меня произошел сбой RAID6, и я вручную собрал 6 из 8 дисков с точно совпадающими счетчиками событий. Однако я не смог mount собранный массив.

Оказалось, что мне нужно использовать резервный суперблок. Бег fsck -b <location> ... в конце концов умер с нехваткой памяти, что привело меня к этой теме / вопросу.

Короче говоря, используя fsck -b <location>... а затем делать ctrl+c позволил мне смонтировать мой массив и восстановить мои файлы.

Спасибо!