From owner-freebsd-arch@FreeBSD.ORG Tue Jan 4 23:47:49 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 3643216A4CE; Tue, 4 Jan 2005 23:47:49 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 744C843D3F; Tue, 4 Jan 2005 23:47:48 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 41F847A425; Tue, 4 Jan 2005 15:47:48 -0800 (PST) Message-ID: <41DB2B24.6050005@elischer.org> Date: Tue, 04 Jan 2005 15:47:48 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: Pawel Jakub Dawidek References: <20050104224043.GM784@darkness.comp.waw.pl> In-Reply-To: <20050104224043.GM784@darkness.comp.waw.pl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: arch@freebsd.org cc: scottl@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: Tue, 04 Jan 2005 23:47:49 -0000 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.