From owner-freebsd-current Tue Mar 18 16:34:57 2003 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 605F337B401; Tue, 18 Mar 2003 16:34:55 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEC7B43F3F; Tue, 18 Mar 2003 16:34:52 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0182.cvx22-bradley.dialup.earthlink.net ([209.179.198.182] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18vRXb-0000jk-00; Tue, 18 Mar 2003 16:34:48 -0800 Message-ID: <3E77BAD3.12447056@mindspring.com> Date: Tue, 18 Mar 2003 16:33:23 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Brad Knowles Cc: Bakul Shah , Julian Elischer , FreeBSD current users , fs@FreeBSD.ORG Subject: Re: Anyone working on fsck? References: <200303180459.XAA15021@goliath.cnchost.com> <3E76C15F.D3C7F9A7@mindspring.com> <3E77A0C0.B1BEA2D7@mindspring.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a453fd58d6e942106ea548b70a2c2bd86e350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Brad Knowles wrote: > At 2:42 PM -0800 2003/03/18, Terry Lambert wrote: > > Make sense now? > > No. > > However, I am now convinced that I don't understand enough of how > the filesystem works to even be able to ask the simplest of questions > about how this process can be improved. So, I will now shut up. You should read the "A Fast Filesystem for UNIX" paper by McKusick, et. al.. The Viva FS paper I mentioned the other day is also good background on placement policies. Actually, I have thought out a (relatively) simple way of making all CG fsck's take a single pass, but it requires access to some free blocks on the FS itself, and it has a worrisome amount of writes that end up happening to the same region of the disk, so I don't know what it means for the failure rate. The only space I can see to grab for it is something like the quota stuff, or to steal inode #1 from the whiteouts. But the resulting fsck could be *guaranteed* to take only a single pass through the data. Further, it could be bounded, to ensure the fsck process does not need to swap data sets in hand (but compared to the single pass optimization, going from O(3)->O(1), that's just gravy). It would only require a single bit change to the superblock, too, if the space was found. Perhaps there is a "don't care" area available for this, like I suggested before UFS2 was started? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message