Skip site navigation (1)Skip section navigation (2)
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>