Огромное количество «многократно заявленных блоков» во время fsck

Основной вопрос:

Сколько времени нужно fsck, чтобы исправить файл размером 100 ГБ (17 миллионов блоков) с блоками с множественным заявлением?

Полная версия вопроса:

После отказа ИБП я столкнулся с сервером Ubuntu 10.04, который упал в fsck при начальной загрузке. Это нормально, обычно покупайте около получаса на устранение различных проблем, соглашаясь с подсказками, достаточно, чтобы вернуть сервер.

Но не сегодня. Сегодня у меня есть огромный список чисел, прокручиваемых в стиле матрицы консоли за добрые несколько минут. В основном это была строка за строкой:

Multiply-claimed blocks in inode xxxxxxxxx

В любом случае, после нескольких минут прокрутки, все наконец успокоилось, и я получил:

Pass 1C: Scanning directories for inodes with multiply-claimed blocks

с последующим...

Pass 1D: Reconciling multiply-claimed blocks

..и..

(There are 32 inodes containing multiply-claimed blocks.)

Звучало не так уж плохо, но потом он начал просматривать некоторые файлы вот так:

File /path/to/a/file

has 1 multiply-claimed block(s) shared with 1 file(s):

/path/to/another/file

Clone multiply-claimed blocks? yes

На этот вопрос мне ответили, и процесс продолжился. Однако на это ушло очень-очень много времени. Часы и часы, хотя это был файл размером всего 2 МБ.

После этого появился аналогичный диалог, но на этот раз для файла образа виртуальной машины, который 100 ГБ и более 17 миллионов блоков, на которые было заявлено несколько раз, совместно с 0 файлом (ами).

Это было 2 дня назад и до сих пор работает.

Итак, возвращаясь к моему первоначальному вопросу, сколько времени это займет? Это безнадежное дело и есть ли альтернативные способы справиться с этим? Чего я действительно не понимаю, так это того, почему сообщается, что файл 100 ГБ используется совместно с 0 файлами, что является противоречием, если я правильно понимаю значение блоков с множественным заявлением.

Это происходит со мной на RAID-массиве из 6 дисков, файловая система ext4 4,5 ТБ. Linux 3.3.7-1-ARCH # 1 SMP PREEMPT i686

Я использую rsync для синхронизации на всех серверах с ext4, и это файлы, которые я в основном получаю от блоков с множественным заявлением и повторяющихся сообщений inode.

Варианты крепления EXT4

Я сделал пару вещей, которые, казалось, помогли, - это убедиться, что ext4 монтируется с поддержкой барьера и данных = заказанные.

/dev/md5 /md5  ext4  defaults,noatime,nouser_xattr,stripe=1536,data=ordered  0 2

Растровое изображение RAID

Другой шаг, который я предпринял, - это включить растровое изображение на RAID.

mdadm --grow /dev/md5 --bitmap=internal

или

mdadm --grow /dev/md5 --bitmap=/external/md5.bitmap

Кажется, что лучше всего работает и растровое изображение рейда, и журнал ext4 на внешнем устройстве.

Автозапуск USB

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

usbcore.autosuspend=-1

Режимы данных EXT4

Из: http://kernel.org/doc/Documentation/filesystems/ext4.txt

Есть 3 различных режима данных:

режим обратной записи В режиме data = writeback ext4 вообще не ведет журнал данных. Этот режим обеспечивает такой же уровень ведения журнала, что и XFS, JFS и ReiserFS в режиме по умолчанию - журналировании метаданных. Сбой + восстановление может привести к появлению неверных данных в файлах, которые были записаны незадолго до сбоя. Этот режим обычно обеспечивает наилучшую производительность ext4.

Упорядоченный режим В режиме данные = упорядоченный ext4 только официально регистрирует метаданные, но логически группирует информацию метаданных, относящуюся к изменениям данных, с блоками данных в единый блок, называемый транзакцией. Когда приходит время записывать новые метаданные на диск, сначала записываются связанные блоки данных. В общем, этот режим работает немного медленнее, чем обратная запись, но значительно быстрее, чем режим журнала>.

режим журнала data = режим журнала обеспечивает полное ведение журнала данных и метаданных. Все новые данные сначала записываются в журнал, а затем в его окончательное место. В случае сбоя журнал можно воспроизвести, приведя данные и метаданные в согласованное состояние. Этот режим является самым медленным, за исключением случаев, когда данные необходимо читать и записывать на диск одновременно, когда он превосходит все другие режимы. В настоящее время ext4 не имеет поддержки отложенного выделения, если выбран этот режим журналирования данных.

Исправить с помощью Debugfs

Здесь есть отличные примеры, которые нужно исправить: http://www.redhat.com/archives/ext3-users/2009-Feb February/msg00021.html

Похоже, что причина большого количества времени, а также загадки многократно заявленных блоков, совместно используемых нулевыми файлами, была результатом деградированного RAID-массива.

Как только я удалил неисправный диск, fsck пошел намного быстрее. Было еще несколько блоков с многократными заявками, но они были исправлены очень быстро.

Я уже сталкивался с ухудшенными RAID-массивами в Ubuntu раньше, и обычно сразу после фазы grub появляется предупреждение, но в данном случае этого не произошло.

Сколько времени это займет, будет зависеть от производительности дисковой подсистемы, устраняемых повреждений и т. Д.

Похоже, есть приличное повреждение файловой системы. Насколько велика фактическая файловая система? Вы сказали, что это файл размером 100 ГБ, а позже это образ виртуальной машины? Это виртуальный сервер? Или вы про виртуальный бокс?

Лично, если бы это заняло больше суток и повреждение было определенно одному файлу, я бы восстановил файл из резервной копии, и, если были какие-либо признаки продолжающихся проблем, переформатировал и восстановил из резервной копии, предполагая, что диск не выходит из строя случайно. У меня проблемы с доверием к файловым системам, которые начинают портиться. Если сам диск не выходит из строя, файловая система может иметь повсеместную проблему, пока она не будет запущена заново.

Но это я.

Думаю, у меня была похожая проблема. У меня есть 2 HDD в массиве RAID0. Однажды я сделал fsck вручную, после того, как я размонтировал устройство. К моей боли, я не осознавал, что виртуальная машина все еще работает и обращается к устройству во время fsck'ed. Результатом было много multiply claimed blocks и поскольку я перезагружал свой сервер во время выполнения, я думаю, что суперблок сломался. Так что я больше не мог даже монтировать RAID.

Я исправил проблему, восстановив суперблок, снова запустив fsck и исправив все проблемы, которые не имели ничего общего с "многократно заявленными блоками". Это заняло у меня некоторое время, и мне нужно было присутствовать на процессе, чтобы сказать fsck не ремонтировать «многократно заявленные блоки».

После этого суперблок был установлен, и я снова смог монтировать устройство. Теперь я несколько раз запустил fsck и проверил, какие файлы были затронуты "многократно заявленными блоками", остановил процесс, нажав ctrl^c и просто скопировал затронутые файлы и один раз удалил оригинал.

Звучит нетрадиционно, но он быстро устранил мои проблемы, и мои жесткие диски кажутся чистыми (согласно e2fsck).

Если бы существовал лучший / более быстрый способ решить эти проблемы, я рад слышать о них.

Вы используете ext2 или ext4 без журнала? Вы никогда не должны увидеть такую ошибку в журнале.

Да, нет смысла иметь многократно заявленные блоки, которые разделяются нулевыми файлами. Вы должны сообщить об этой ошибке в списке рассылки linux-ext4@vger.kernel.org.