Date: Fri, 3 Sep 2004 23:45:17 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Marc G. Fournier" <scrappy@hub.org> Cc: freebsd-current@freebsd.org Subject: Re: what is fsck's "slowdown"? Message-ID: <200409040645.i846jHwn041383@apollo.backplane.com> References: <200409032158.i83LwdWg030214@gw.catspoiler.org> <20040904003222.J812@ganymede.hub.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
-Matt
Matthew Dillon
<dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200409040645.i846jHwn041383>