From owner-freebsd-current Mon Feb 24 13:37:32 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 6EDE137B401 for ; Mon, 24 Feb 2003 13:37:31 -0800 (PST) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C53E43FBF for ; Mon, 24 Feb 2003 13:37:30 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0300.cvx22-bradley.dialup.earthlink.net ([209.179.199.45] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18nQHu-0004x1-00; Mon, 24 Feb 2003 13:37:27 -0800 Message-ID: <3E5A9043.CCFE4A84@mindspring.com> Date: Mon, 24 Feb 2003 13:36:03 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Darryl Okahata Cc: current@FreeBSD.ORG Subject: Re: Vinum R5 [was: Re: background fsck deadlocks with ufs2 and big disk] References: <200302241818.KAA22896@mina.soco.agilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a465d02ab30e0ff8aca07fe039a670981d93caf27dac41a8fd350badd9bab72f9c350badd9bab72f9c 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 Darryl Okahata wrote: > Terry Lambert wrote: > > I think this is an expected problem with a lot of concatenation, > > whether through Vinum, GEOM, RAIDFrame, or whatever. > > > > This comes about for the same reason that you can't "mount -u" > > to turn Soft Updates from "off" to "on": Soft Updates does not > > tolerate dirty buffers for which a dependency does not exist, and > > will crap out when a pending dirty buffer causes a write. > > Does this affect background fsck, too (on regular, non-vinum > filesystems)? From what little I know of bg fsck, I'm guessing not, but > I'd like to be sure. Thanks. No, it doesn't. Background fsck works by assuming that the only thing that could contain bad data is the cylinder group bitmaps, which means the worst case failure is some blocks are not available for reallocation. It works by taking a snapshot, which is a feature that allows modification of the FS while the bgfsck's idea of the FS remains unchanged. Then it goes through the bitmaps, verifying that the blocks it thinks are allocated are in fact allocated by files within the snapshot. Basically, it's only job is really to clear bits in the bitmap that represent blocks for which there are no files referencing them. There are situations where bgfsck can fail, sometimes catastrophically, but they are unrelated to having dirty blocks in memory for which no updates have been created. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message