resize2fs кажется застрявшим на этапе 3 (сканирование таблицы узлов) - что делать?

Question

У меня есть машина под управлением Arch Linux (я полагаю, 2010) с массивом RAID-5 6 ТБ, подключенным к Highpoint RocketRaid 2320. У меня были проблемы с драйверами RAID-контроллера и последними ядрами Linux, так как драйвер не был открытым исходным кодом, и в результате я перенес систему на Windows Server.

Проблема в том, что диск объемом 6 ТБ изначально состоял только из раздела ext4. Я сжал раздел настолько, насколько мог, и добавил раздел NTFS в пустое пространство, чтобы я мог начать перемещать файлы. Это прошло хорошо. Проблема заключается в том, что теперь мне нужно сжать раздел ext4 снова, перемещать файлы, термоусадочные снова и т.д. Второй прогон через resize2fs занимает намного больше времени, чем первый. Кажется, застревает на проходе 3:

[root@nar-shaddaa rc.d]# resize2fs -p /dev/sdb3 863000000
resize2fs 1.41.14 (22-Dec-2010)
Resizing the filesystem on /dev/sdb3 to 863000000 (4k) blocks.
Begin pass 2 (max = 29815167)
Relocating blocks             XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 36670)
Scanning inode table          XXXXXXXXXXX-----------------------------

Он сидел так, поглощая 100% одного ядра более 19 часов:

[root@nar-shaddaa rc.d]# ps aux | grep resize2fs
root     16277 94.1 19.8 627096 613940 pts/1   R+   Jun15 1184:37 resize2fs -p /dev/sdb3 863000000

Первоначально я пробежал через resize2fs -P /dev/sdb3 чтобы получить минимальный размер раздела, но для безопасности я округлился до ближайшего миллионного блока (отсюда даже 863 миллиона). Перед запуском resize2fs e2fsck сообщил, что файловая система чистая:

[root@nar-shaddaa rc.d]# e2fsck -yv /dev/sdb3
e2fsck 1.41.14 (22-Dec-2010)
x-files: clean, 286672/300400640 files, 867525660/1201576187 blocks

Я обеспокоен тем, что это происходит гораздо дольше, чем первое изменение размера (которое заняло чуть меньше часа), и я, кажется, вообще не получаю какого-либо обновления от resize2fs, хотя он явно засасывает циклы процессора , Жду ли я дольше (и если да, то как долго)? Или я могу отменить его и использовать другой инструмент для изменения размера раздела?

Answer 1

Я наконец понял, что это было. После отмены исходного изменения размера (просто ctrl+C) я запустил e2fsck -f -y /dev/sdb3 чтобы исправить любые проблемы, которые я сделал. Я смог смонтировать раздел еще в исходном размере, поэтому данные не были потеряны. Затем я запустил resize2fs с флагом отладки (resize2fs -d 14 <xxx>) и заметил, что он застрял в постоянном цикле, пытаясь переместить часть инодов.

Я наконец-то заставил его работать, используя более старую версию e2fsprogs. Я поместил Ubuntu 9.10 (Karmic Koala) на флешку, загрузился в нее, установил драйверы rr232x с открытым исходным кодом, чтобы я мог манипулировать массивом, и запустил старую версию e2fsprogs (resize2fs 1.41.9 (22 августа 2009 г.) , если быть точным).

Первоначально я пробовал resize2fs -p /dev/sdb3 863000000 , и он сказал мне, что для этого требуется ~ 26 миллионов блоков. Поэтому я взял целевой размер, добавил к нему и сделал resize2fs -p /dev/sdb3 1000000000 . Через 10 минут меня приветствует сообщение:

/dev/sdb3 теперь на 1000000000 блоков

Теперь я думаю, что главный вопрос в том, почему более новая версия e2fsprogs не могла / не сказала мне, что я просил слишком маленький размер (и почему он предлагал такой маленький размер в первую очередь)?