From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 07:59:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A329A16A4CE; Sat, 4 Sep 2004 07:59:48 +0000 (GMT) Received: from pimout2-ext.prodigy.net (pimout2-ext.prodigy.net [207.115.63.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1582343D39; Sat, 4 Sep 2004 07:59:48 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (adsl-69-104-103-54.dsl.snfc21.pacbell.net [69.104.103.54])i847xhK6151412; Sat, 4 Sep 2004 03:59:44 -0400 Message-ID: <413975EE.4030400@elischer.org> Date: Sat, 04 Sep 2004 00:59:42 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.4b) Gecko/20030524 X-Accept-Language: en, hu MIME-Version: 1.0 To: Don Lewis References: <200409040709.i8479U79031043@gw.catspoiler.org> In-Reply-To: <200409040709.i8479U79031043@gw.catspoiler.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: what is fsck's "slowdown"? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2004 07:59:48 -0000 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..