resize2fs, кажется, застрял на перевале 3 (таблица инф. узлов сканирования) - что делать?

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

проблема в том, что диск емкостью 6 ТБ изначально состоял только из раздела ext4. Я сжал раздел настолько, насколько мог, и добавил NTFS раздел в пустом пространстве, чтобы я мог начать перемещать файлы. Все прошло хорошо. Проблема в том, что теперь мне нужно уменьшить ext4 раздел снова, двиньте архивы, сожмите снова, etc. Второй запуск через 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

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

1
задан Journeyman Geek
07.05.2023 1:37 Количество просмотров материала 2622
Распечатать страницу

1 ответ

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

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

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

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

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

2
отвечен JonnyFunFun 2023-05-08 09:25

Постоянная ссылка на данную страницу: [ Скопировать ссылку | Сгенерировать QR-код ]

Ваш ответ

Опубликуйте как Гость или авторизуйтесь

Имя
Вверх