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@ws-aschultz:~# df -i /usr/src2/ Filesystem Inodes IUsed IFree IUse% Mounted on /dev/sdb1 30523392 1401574 29121818 5% /usr/src2 root@ws-aschultz:~# df /usr/src2/ Filesystem 1K-blocks Used Available Use% Mounted on /dev/sdb1 240308484 196091320 32010176 86% /usr/src2 root@ws-aschultz:~# umount /usr/src2 root@ws-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
Attachment:
signature.asc
Description: This is a digitally signed message part.
