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)
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?

  • Cancelling it now will probably kill your partition. If it tells you to wait, it is suggested you wait, unless you can afford to lose your partition. – new123456 Jun 16 '11 at 18:08
  • I guess the main question is how long is too long to wait? This thing has shown absolutely no progress at all since it started, and continues to show no signs of life other than taking ~95-100% of a single core... – JonnyFunFun Jun 21 '11 at 17:57
  • Be prepared to wait, are you expanding this partition and if so what was it originally sized at and what was the partition table you used? – Cereal Jun 21 '11 at 18:05
  • Shrinking the partition. Partition table is GPT. The original size was ~6TB, shrunk the first time down to ~4.5. I was looking to bring that down about another TB, move data to the other partition, wash hands, repeat process. – JonnyFunFun Jun 22 '11 at 12:53

I finally figured out what it was. After cancelling the original resize (just a simple ctrl+C), I ran e2fsck -f -y /dev/sdb3 to correct any issues I made. I was able to mount the partition still under the original size, so no data was lost. I then ran resize2fs with the debug flag (resize2fs -d 14 <xxx>) and noticed that it was stuck in a constant loop trying to relocate a chunk of inodes.

I finally got it to work by using an older version of e2fsprogs. I put Ubuntu 9.10 (Karmic Koala) on a USB stick, booted into it, installed the open-source rr232x drivers so I could manipulate the array, and ran the older version of e2fsprogs (resize2fs 1.41.9 (22-Aug-2009), to be exact).

I had originally tried the resize2fs -p /dev/sdb3 863000000, and it had told me that it required ~26 million blocks. So I took the target size, added that to it and did resize2fs -p /dev/sdb3 1000000000. 10 minutes later I'm greeted with the message:

/dev/sdb3 is now at 1000000000 blocks

Now I guess the ultimate question is why the newer version of e2fsprogs couldn't/wouldn't tell me that I was asking for too small a size (and why it offered a size that small in the first place)?

| improve this answer | |
  • 1
    To help others avoid the problem, what was the version of the failing resize2fs on you Arch box? – akaihola Jan 20 '12 at 12:48
  • Version 1.41.14 – JonnyFunFun Feb 21 '12 at 15:29
  • I have a similar problem as far as symptoms but my resize operation has 50G of overhead. As I understand your solution it works because it gives the system a little more overhead no? – Caleb Jul 29 '13 at 13:19

This isn't much of an answer but in my case, the wrong disk was being resized. I was expecting sda to be 120GB but instead my 25T storage shelf was being resized.

Anaconda's inventory of devices didn't match CentOS's, which saw it as sde. Therefore, my Clonezilla restore got "stuck" when it was trying to restore on a 25T sda. If I had waited multiple days, it may have finished at some point.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.