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
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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
--Carlos
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