Re: what is fsck's "slowdown"?

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
userland.

>> 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.