I have a machine running Arch Linux (2010, I believe) with a 6TB RAID-5 array hooked up to a Highpoint RocketRaid 2320. I've been having issues with the RAID controller's drivers and the latest Linux kernels thanks to the driver not being open-source, and as a result I am migrating the system to Windows Server.
Problem is that the 6TB disk originally was comprised only of an ext4 partition. I shrunk the partition down as much as I could, and added a NTFS partition in the empty space so I could start moving files. That went fine. Problem is that now I need to shrink the ext4 partition again, move files, shrink again, etc. The second run through resize2fs is taking way longer than the first pass. It seems to be getting stuck at pass 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-----------------------------
It has been sitting this way, sucking up 100% of one core for more than 19 hours now:
[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
I had originally run through
resize2fs -P /dev/sdb3 to get the minimum partition size, but to be safe I rounded up to the nearest millionth block (hence the even 863 million). Prior to starting resize2fs, e2fsck reported the file system as clean:
[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
I'm concerned because this has been going on for far longer than the first resize took (which was just under an hour), and I do not appear to be getting any sort of update from resize2fs at all yet it is clearly sucking CPU cycles. Do I wait longer (and if so, how long)? Or do I cancel it and use a different tool to resize the partition down?