linux-ext4 - resize2fs shrink ext3 can be CPU limited

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:	Thu, 10 Feb 2011 19:23:54 -0800
From:	John Reiser <jreiser@...wagon.com>
To:	linux-ext4@...r.kernel.org
Subject: resize2fs shrink ext3 can be CPU limited

Hi,

When I use resize2fs to shrink a 153GB ext3 from about 53% full
to about 55% of its original size (thus becoming about 98% full),
then Pass 3, Scanning inode table, is CPU limited and a significant
fraction of elapsed wall-clock time (tens of minutes out of more than
an hour).  Being CPU-limited for such a duration seems peculiar to me.

The behavior is reproducible.  The details are at
  https://bugzilla.redhat.com/show_bug.cgi?id=676683
including reports from oprofile.

  resize2fs 1.41.12 (17-May-2010)
    input: 1071971/9863168 files (0.1% non-contiguous), 21597266/39423744
    output: The filesystem on /dev/sdc2 is now 22989038 blocks long.
real 69m52.167s
user 26m29.431s
sys 2m3.456s

[I'm not subscribed to this mailing list.]

-- 
John Reiser, jreiser@...Wagon.com
--
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