Shrinking ext3 partition takes long and high CPU usage

Shrinking ext3 partition takes long and high CPU usage

[Marcel van Beurden]

Hi,

I'm in the process of shrinking a 900 GB ext3 partition on a USB2 
connected disk using Gparted (0.5.1-1ubuntu3). The whole thing has been 
running for 2 days now and I'm curious whether it will ever finish. 
Right now the resize2fs (sub)process is using 99% of one 3.2GHz Xeon 
core (totalling up to 32 hours of CPU time so far).

Is resize2fs being stuck and hanging forever, or is it just taking a lot 
of time? I wouldn't expect resizing to be so CPU intensive.

Is there any way to check whether it is still doing anything and to 
estimate when it will be done?
How corrupt will be filesystem be when I press ctrl-C?

Version of resize2fs is: 1.41.11 (14-Mar-2010)
Version of linux kernel:  2.6.32-40-generic-pae

Regards,
Marcel

Re: Shrinking ext3 partition takes long and high CPU usage

[Carlos Maiolino]

On Fri, Oct 19, 2012 at 11:34:26AM +0200, Marcel van Beurden wrote:
> Hi,
> 
> I'm in the process of shrinking a 900 GB ext3 partition on a USB2
> connected disk using Gparted (0.5.1-1ubuntu3). The whole thing has
> been running for 2 days now and I'm curious whether it will ever
> finish. Right now the resize2fs (sub)process is using 99% of one
> 3.2GHz Xeon core (totalling up to 32 hours of CPU time so far).
> 
> Is resize2fs being stuck and hanging forever, or is it just taking a
> lot of time? I wouldn't expect resizing to be so CPU intensive.
> 
Hi, is not possible to answer this with just the information you provided. I
would expect to see soft lockup warnings on the system log if it was really
stuck.

A stack trace of the resize2fs process (sysrq-t) might give some information
about what's going on.

You're using a too olde resize2fs so, may be possible you're using a buggy
version too, but I'm not the best person to say if there was any bug on
resize2fs which might be causing this.

Also, I hope you're trying to shrink the filesystem with this umounted :-)

> Is there any way to check whether it is still doing anything and to
> estimate when it will be done?
> How corrupt will be filesystem be when I press ctrl-C?
> 
> Version of resize2fs is: 1.41.11 (14-Mar-2010)
> Version of linux kernel:  2.6.32-40-generic-pae
> 
> Regards,
> Marcel
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
--Carlos

Re: Shrinking ext3 partition takes long and high CPU usage

[Marcel van Beurden]

Hi,

A follow-up...

 >> Is resize2fs being stuck and hanging forever, or is it just taking a
>> lot of time? I wouldn't expect resizing to be so CPU intensive.
>>
> Hi, is not possible to answer this with just the information you provided. I
> would expect to see soft lockup warnings on the system log if it was really
> stuck.

There was no information in any log.

> You're using a too olde resize2fs so, may be possible you're using a buggy
> version too, but I'm not the best person to say if there was any bug on
> resize2fs which might be causing this.

Yeah, it was not an up-to-date system. I just used whatever I had available.

> Also, I hope you're trying to shrink the filesystem with this umounted :-)

It was unmounted.

According to my calculations (using the data rate that iotop showed me), 
it would take forever. So I decided to cancel the resize process. Then I 
ran e2fsck on it which gave me plenty of errors like this one:

Multiply-claimed block(s) in inode 2879754: 43528289 43528290 43528291 
43528292 43528293 43528294 43528295 43528296 43528297 43528298 43528299 
43528300 43528301 43528302 43528303 43528304 43528305 43528306

And after that it crashed with this message:

e2fsck: Can't allocate block element
e2fsck: aborted

Since the disk still seemed readable, I copied all files to another disk 
and it did that without complaining. Not sure how many files are 
missing/corrupted. So far I found some empty directories and one regular 
file that was 0 bytes.

Lessons learned:
1. Always use up-to-date software
2. Be careful that when meaning to resize a partition, you don't 
accidentally move it (round to cylinders in gparted?)
3. Get the USB disk out of it's enclosure and hook it up to a SATA port

Regards,
Marcel