From owner-freebsd-current@FreeBSD.ORG Sat Sep 4 19:20:36 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 C622416A4CE for ; Sat, 4 Sep 2004 19:20:36 +0000 (GMT) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78D8143D39 for ; Sat, 4 Sep 2004 19:20:36 +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 i84JKTKw032364; Sat, 4 Sep 2004 12:20:33 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200409041920.i84JKTKw032364@gw.catspoiler.org> Date: Sat, 4 Sep 2004 12:20:29 -0700 (PDT) From: Don Lewis To: scrappy@hub.org In-Reply-To: <200409040830.i848U4jN031148@gw.catspoiler.org> 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 19:20:36 -0000 On 4 Sep, Don Lewis wrote: > On 4 Sep, Marc G. Fournier wrote: >> On Fri, 3 Sep 2004, Don Lewis wrote: > >>> Would the file system in question happen to be full of UNREF files that >>> fsck is deleting? >> >> mostly 'ZERO LENGTH DIRECTORY' ... > > I'm pretty sure that I understand the problem now. During pass 4, fsck > looks at each inode. It checks each inode in the FSTATE and DFOUND > states to see if their link counts need to be adjusted. If the link > count does not need to be adjusted, fsck checks to see if the inode is > on the list of inodes whose initial link counts were zero, and if it > finds the inode on this list, it clears the inode. > > The problem is that the zero length directories get added to this list > if their initial link count is zero, and they also don't get removed > from the list because they are in the DCLEAR state, so the list doesn't > shrink. This bloats the list, which greatly slows down processing of > normal files and directories. > > Deleting unreferenced files is not the biggest bottleneck, so reversing > the order of the list isn't going to help much. Probably the biggest > speedup could be gained by keeping the zero length directories off the > list. An even better solution would be to dispense with the zln list entirely and just set a bit for these inodes in their struct inostat. This change is a bit more intrusive because of the need for some sort of packing strategy because of the need to keep this structure small. My initial inclination would be to add two new states, FZERO and DZERO, that pass1() would use to mark inodes with a zero link count.