From owner-freebsd-current@FreeBSD.ORG Mon Sep 1 20:31:47 2003 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 F3AB316A4BF for ; Mon, 1 Sep 2003 20:31:46 -0700 (PDT) Received: from gate.bitblocks.com (bitblocks.com [209.204.185.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5346843FF3 for ; Mon, 1 Sep 2003 20:31:44 -0700 (PDT) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost [127.0.0.1]) by gate.bitblocks.com (8.12.9/8.12.9) with ESMTP id h823VgAX040906; Mon, 1 Sep 2003 20:31:43 -0700 (PDT) (envelope-from bakul@bitblocks.com) Message-Id: <200309020331.h823VgAX040906@gate.bitblocks.com> To: Terry Lambert In-reply-to: Your message of "Mon, 01 Sep 2003 19:51:57 PDT." <3F5405CD.C5534CBF@mindspring.com> Date: Mon, 01 Sep 2003 20:31:42 -0700 From: Bakul Shah cc: freebsd-current@freebsd.org Subject: Re: swapon vs savecore dilemma 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: Tue, 02 Sep 2003 03:31:47 -0000 > > Is fsck really that memory heavy so that it needs swap? > > Yes, if you have a huge FS. > > The problem is that the checking of the CG bitmaps during an fsck > require that you have all the bitmaps in core Hmm.... For a one TB FS with 8KB block size you need 2^(40-13) bits to keep track of blocks. That is 2^24 bytes or 16Mbytes. That doesn't seem so bad (considering that you really should have a lot more RAM if you are playing terrybytes of data). > My suggestion (which has been my suggestion all along) is to add > two date stamped CG bitmap bitmaps somewhere (my favorite place > for this is to steal space at the front of inode 1, which is used > only rarely, since people don't use the whiteout feature, and > which can be made compatible with whiteouts, in any case). This is the old stable storage idea. You need a generation number rather than a date stamp but the idea is the same. Something needs to be done so that time to fsck depends on the outstanding FS traffic at the time of the crash rather than the size of the FS (especially when you are dealing with multi terabytes of data).