linux-ext4 - Re: "tune2fs -I 256" runtime---can it be interrupted safely?

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]

Message-Id: <200811161311.29107.aschultz@warp10.net>
Date:	Sun, 16 Nov 2008 13:11:23 +0100
From:	Andreas Schultz <aschultz@...p10.net>
To:	Theodore Tso <tytso@....edu>
Cc:	Andreas Dilger <adilger@....com>, linux-ext4@...r.kernel.org,
	Aneesh Kumar <aneesh.kumar@...ux.vnet.ibm.com>
Subject: Re: "tune2fs -I 256" runtime---can it be interrupted safely?

Hi,

On Saturday 15 November 2008 06:50:17 Theodore Tso wrote:

> Fixing both of these should remove most of the user-space time that's
> being burned by tune2fs -I 256.  There is still some CPU burned by the
> undo file, and indeed we can probably speed this up some more by
> omitting creating an undo entry when we're copying a data block to a
> previously unused block.  But hopefully this should be enough to speed
> up "tune2fs -I 256" for most people.

it does speed up things, but it is still quite slow. I tried it on a 250GB partition which is about 86% filled:

root@...aschultz:~# df -i /usr/src2/
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sdb1            30523392 1401574 29121818    5% /usr/src2
root@...aschultz:~# df /usr/src2/
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sdb1            240308484 196091320  32010176  86% /usr/src2
root@...aschultz:~# umount /usr/src2
root@...aschultz:~# time tune2fs -I 256 /dev/sdb1
tune2fs 1.41.3 (12-Oct-2008)
Setting inode size 256

real    64m31.189s
user    43m46.708s
sys     1m50.627s

64min for 250GB seems to be to much for the average user.

From watching the disc activity and the output of 'top', it seems that the operation periodically consumes 100%CPU for extended periods without any disc activity, followed by a brief period of about 20%CPU load and light disc activity.

Andreas

Download attachment "signature.asc " of type "application/pgp-signature" (198 bytes)