From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 07:09:47 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 A278216A4CE for ; Sat, 4 Sep 2004 07:09:47 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 62B6643D49 for ; Sat, 4 Sep 2004 07:09:47 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.12.11/8.12.11) with ESMTP id i8479U79031043; Sat, 4 Sep 2004 00:09:34 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200409040709.i8479U79031043@gw.catspoiler.org> Date: Sat, 4 Sep 2004 00:09:30 -0700 (PDT) From: Don Lewis To: dillon@apollo.backplane.com In-Reply-To: <200409040645.i846jHwn041383@apollo.backplane.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii 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:09:47 -0000 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.