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, 2011 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... Jun 21, 2011 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, 2011 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. Jun 22, 2011 at 12:53

3 Answers 3


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

  • 1
    To help others avoid the problem, what was the version of the failing resize2fs on you Arch box?
    – akaihola
    Jan 20, 2012 at 12:48
  • Version 1.41.14 Feb 21, 2012 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, 2013 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.


1: some people mention that during online resize, df -h may show changing values.

2: offline reduce from 7.8T to 6.8T takes for me about 10-20 mn (with 6.6T used - free/used space ratio is important in this matter).

3: on the same machine, online grow from 6.8T to 7.6T took exactly 2h (1h50'31"). So this is counter intuitive to me, but online grow took about 8 times longer than offline shrink.

I did not intend to perform online grow, but after umount, I had a hidden mount point not shown by df -h (I had not checked mount ; only df).


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .