what is fsck's "slowdown"?
julian at elischer.org
Sat Sep 4 00:59:48 PDT 2004
Don Lewis wrote:
> On 3 Sep, Matthew Dillon wrote:
>> There may be some tricks you can use to improve your fsck times on that
>> large partition.
>> The first thing you can try is to compile up an fsck with a much larger
>> in-program disk buffer cache. cd into /usr/src/sbin/fsck and edit
>> fsck_ffs/fsck.h. Significantly increase MAXBUFSPACE and INOBUFSIZE.
>> e.g. try increasing MAXBUFSPACE from 40MB to 200MB, and INOBUFSIZE from
>> 56MB to 200MB.
>> Another possibility would be to try to improve disk I/O linearity by
>> modifying getdatablk() in fsutil.c to read-ahead several blocks rather
>> then just one. This would require some programming.
>> The remaining tricks involve reformatting the large partition to
>> increase the block size and/or increase the number of bytes/inode
>> (thus reducing the number of inodes). The larger the block size, the
>> easier it is for fsck to track down indirect blocks. The fewer inodes
>> the partition has, the less work fsck has to do. But, of course, to do
>> this you have to backup all the data on the partition, newfs it with
>> the new parameters, and restore all the data back. Maximizing the
>> number of cylinders/group also helps a great deal but I think newfs
>> already does that by default.
> This sort of thing was my initial thought, but the posted CPU usage
> statistics show that fsck is burning up most of its CPU cycles in
>>>load: 0.99 cmd: fsck 67 [running] 15192.26u 142.30s 99% 184284k
> Increasing MAXBUFSPACE looks like it would make the problem worse
> because getdatablk() does a linear search.
> freebsd-current at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
if you are using an alternate superblock then teh hash routines devolve into
a single linked list.. make si treally sloww..
More information about the freebsd-current