From owner-freebsd-arch@FreeBSD.ORG Wed Jan 5 07:10:08 2005 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE84516A4CE for ; Wed, 5 Jan 2005 07:10:08 +0000 (GMT) Received: from pimout3-ext.prodigy.net (pimout3-ext.prodigy.net [207.115.63.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6761543D2F for ; Wed, 5 Jan 2005 07:10:08 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [192.168.1.102] (adsl-216-100-134-143.dsl.snfc21.pacbell.net [216.100.134.143])j057A5Hg386634; Wed, 5 Jan 2005 02:10:06 -0500 Message-ID: <41DB92C9.50801@elischer.org> Date: Tue, 04 Jan 2005 23:10:01 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8a3) Gecko/20041017 X-Accept-Language: en, hu MIME-Version: 1.0 To: Peter Jeremy References: <20050104224043.GM784@darkness.comp.waw.pl> <41DB2B24.6050005@elischer.org> <20050105044626.GI34222@cirb503493.alcatel.com.au> In-Reply-To: <20050105044626.GI34222@cirb503493.alcatel.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org Subject: Re: BigDisk project: du(1) 64bit clean. X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2005 07:10:09 -0000 Peter Jeremy wrote: > On Tue, 2005-Jan-04 15:47:48 -0800, Julian Elischer wrote: > >>One thing that needs to be done is an 2ndary storage fsck. >>that doesn't try put everything in RAM. > > > Agreed but VM is different to physical RAM. > > >>Basically this will mean extracting all the metadata from filesystems into >>files and running sort operations of various kinds on them >>to order the data in ways that allows consistencies to be checked. > > > How do you determine where the disk space comes from? You can't > safely use the filesystem being checked because you can't safely write > to it until the fsck has completed. _Any_ filesystem picked > automatically may not have sufficient free space to do an fsck. > (Older Unices prompted for a temporary directory for work files). One assumes you also have a smaller (say 100GB temp filesystem that you can newfs on boot.. or some other similar system.. Here we have our own fsck that acts differently, and we do /var with the regular fsck first and then use it as a place to store the logfiles of the main fsck runs on our TB raids using our modified fsck. > > Overall, the most likely location for free space is swap. I'd therefore > suggest that rather than moving back to using temporary files, we look > at how to better use swap space: swap may not be big enough either.. > - Look into reducing VM requirements (600MB per TB seems high) I only report what it does.. > - Tweak data structures to maximise locality of reference (traversing > linked lists is extremely slow when your list won't fit into RAM) > - Give fsck the ability to split into multiple processes to avoid process > size limits - usr socketpair()s to allow a "master" process to delegate > work ala dump(8). still only DELAYs the problem. > > The downside of using swap is the possibility of over-writing a crash dump. >