Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 04 Sep 2004 00:59:42 -0700
From:      Julian Elischer <julian@elischer.org>
To:        Don Lewis <truckman@freebsd.org>
Cc:        freebsd-current@freebsd.org
Subject:   Re: what is fsck's "slowdown"?
Message-ID:  <413975EE.4030400@elischer.org>
In-Reply-To: <200409040709.i8479U79031043@gw.catspoiler.org>
References:  <200409040709.i8479U79031043@gw.catspoiler.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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
> 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.
> 
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

if you are using an alternate superblock then teh hash routines devolve into
a single linked list.. make si treally sloww..




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?413975EE.4030400>