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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
