From owner-freebsd-fs@FreeBSD.ORG Thu Sep 4 13:25:27 2003 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3604D16A4BF; Thu, 4 Sep 2003 13:25:27 -0700 (PDT) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C7B943F3F; Thu, 4 Sep 2003 13:25:26 -0700 (PDT) (envelope-from julian@elischer.org) Received: from interjet.elischer.org ([12.233.125.100]) by attbi.com (rwcrmhc11) with ESMTP id <2003090420252501300g9gqve>; Thu, 4 Sep 2003 20:25:25 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id NAA42450; Thu, 4 Sep 2003 13:25:25 -0700 (PDT) Date: Thu, 4 Sep 2003 13:25:23 -0700 (PDT) From: Julian Elischer To: Andrew Kinney In-Reply-To: <3F573729.8917.53574D7@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-hackers@freebsd.org cc: fs@freebsd.org Subject: Re: 20TB Storage System (fsck????) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2003 20:25:27 -0000 On Thu, 4 Sep 2003, Andrew Kinney wrote: > > > > Our experience has been that with 4GB of RAM (or more) you > really must increase your KVA to 2GB, leaving only 2GB of UVA. > So, I would concur with what Julian said. > > thrown> ;-) > > With the lack of third party filesystem support in FreeBSD, might > you be better served by looking at a Linux system running > ReiserFS or one of the other file systems designed for such > behemoth disk systems? > > These days, I think Sun even gives away Solaris licenses with their > low end x86 servers, so that might even be an option. > > UFS is great, but there are other filesystems out there that have > already addressed such problems from their use in academic, > government, and scientific computing where gigantic filesystems > tend to be more prevalent. > UFS2 will make the filesystem.. All we need is a way to FIX such a filesystem. My brief analysis of this indicates that a 'serial' fsck should be possible. What this would do is read through the filesystem metadata, creating several 'list' files on another filesystem. These would then be duplicated and sorted on several different fields, and then recombined in a 'merge' manner, to produce lists of unallocated files, bad directory entries, duplicate allocated blocks etc. etc. This would probably be workable in a similar order of magnitute of time as a normal fsck, except 'offline' and able to handle a much larger filesystem. julian