у меня есть машина под управлением 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 на всех, но это явно сосать циклы процессора. Могу ли я ждать дольше (и если да, то как долго)? Или отменить его и использовать другой инструмент для изменения размера раздела вниз?