From owner-freebsd-arch@FreeBSD.ORG Wed Jan 5 03:36:11 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 AD0ED16A4CE; Wed, 5 Jan 2005 03:36:11 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9EC543D3F; Wed, 5 Jan 2005 03:36:10 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.1/8.13.1) with ESMTP id j053Yg0w052603; Tue, 4 Jan 2005 20:34:42 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Tue, 04 Jan 2005 20:35:02 -0700 (MST) Message-Id: <20050104.203502.85411551.imp@bsdimp.com> To: julian@elischer.org From: "M. Warner Losh" In-Reply-To: <41DB2B24.6050005@elischer.org> References: <20050104224043.GM784@darkness.comp.waw.pl> <41DB2B24.6050005@elischer.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: scottl@freebsd.org cc: pjd@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 03:36:11 -0000 In message: <41DB2B24.6050005@elischer.org> Julian Elischer writes: : : : Pawel Jakub Dawidek wrote: : : >Hi. : > : >I want you to look at two patches which makes du(1) 64bit clean. : >This work is part of the BigDisk project: : > : > http://www.freebsd.org/projects/bigdisk/ : > : > : One thing that needs to be done is an 2ndary storage fsck. : that doesn't try put everything in 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. : It will take a bit longer than a RAM fsck but maybe not as much as : one might fear. : We all remember those "sort a mag-tape larger than RAM" : lessons from CS101 don't we? : At least it doesn't have to be "in place" so merge sorts are OK. :-) : : why? : : A bitmap of 1TB of 512 byte records is 244MB so with a 4BG machine : with 3GB available to the process you can't even fit the bitmaps into : memory for a 12TB Filesystem let alone other metadata. : : Going to 2048 byte frags helps but you still run into a limit. : last I tried it, you need about 600MB per TB of fileysstem to check. : : So I think a special fsck that uses files is a must for really big : filesystems, unless they (the filesystems) can be broken up in : a logical way (IBM did that many years ago I believe). : I think you should add that to your list. I think that a big amount of this could be reduced by using simple arrays rather than lists which are more memory efficient... Warner