lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Mon, 22 Oct 2012 11:42:35 +0200
From:	Marcel van Beurden <marcel_linux-ext4@...snix.nl>
To:	linux-ext4@...r.kernel.org
Subject: Re: Shrinking ext3 partition takes long and high CPU usage

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ