From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 20:20:49 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 98D3016A4CE; Sat, 4 Sep 2004 20:20:49 +0000 (GMT) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AA1A43D3F; Sat, 4 Sep 2004 20:20:49 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.12.11/8.12.11) id i84KKXJw041272; Sat, 4 Sep 2004 15:20:33 -0500 (CDT) (envelope-from dan) Date: Sat, 4 Sep 2004 15:20:33 -0500 From: Dan Nelson To: Matthew Dillon Message-ID: <20040904202033.GC6279@dan.emsphone.com> References: <200409040709.i8479U79031043@gw.catspoiler.org> <200409041723.i84HNi4Q046252@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200409041723.i84HNi4Q046252@apollo.backplane.com> X-OS: FreeBSD 5.3-BETA2 X-message-flag: Outlook Error User-Agent: Mutt/1.5.6i cc: Don Lewis 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 20:20:49 -0000 In the last episode (Sep 04), Matthew Dillon said: > :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. > > Oh my. I didn't even notice. That code dates all the way back to > 1994 so I wont bash the author too badly, but it is pretty aweful > coding. > > Hashing the buffer cache is trivial. I'll do it for DragonFly and > post the patch as a template for you guys to do it in FreeBSD (or you > could just do it on your own, it really does look trivial). In my tests, the lookup time for the cache was basically zero, and prefetching disk blocks helped much more. This is on mainly-static filesystems under 80gb holding lots of small files (ports and other cvs tree, cvs repos, etc). The hardest part was dealing with the fact that the bp list doesn't cache disk blocks but arbitrary-sized objects, each any of which may be dirtied by a later write. If you prefech N bytes, you need to add N/objectsize separate entries to the cache. Simply instrumenting getdatablk to print the offest and size of each read, plus whether it was a cache hit, should generate all the data you need to determine what kind of optimizations are useful. -- Dan Nelson dnelson@allantgroup.com