From owner-freebsd-arch Tue Mar 4 15:40:37 2003 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 3062237B401 for ; Tue, 4 Mar 2003 15:40:35 -0800 (PST) Received: from bricore.com (adsl-64-168-71-68.dsl.snfc21.pacbell.net [64.168.71.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2C8F43FA3 for ; Tue, 4 Mar 2003 15:40:33 -0800 (PST) (envelope-from lchen@briontech.com) Received: from luoqi (luoqi.bricore.com [192.168.1.63]) by bricore.com (8.12.6/8.12.6) with SMTP id h24NeS3q016603; Tue, 4 Mar 2003 15:40:28 -0800 (PST) (envelope-from lchen@briontech.com) From: "Luoqi Chen" To: "Jeff Roberson" Cc: Subject: RE: vtruncbuf() Date: Tue, 4 Mar 2003 15:43:25 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <20030304010228.P72102-100000@mail.chesapeake.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Virus-Scanned: by amavisd-milter (http://amavis.org/) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > > > vtruncbuf() does a few things that I'm not terribly certain I > understand. > > > I'm hoping someone can elaborate on this. > > > > > I think the idea was to avoid calling fsync. > > Why does it need to be synced at all? > There was no metadata sync when vtruncbuf() was first introduced, but after some nasty crashes, John Dyson added the metadata sync code. It has been a long time and I don't remember now how the crashes were triggered (or if I had ever understood the mechanism). But now I look at the code, it may have something to do with getting rid of softupdate dependencies associated with these indirect blocks (B_DELWRI), before modifying their contents. > > > Firstly, it makes assumptions about negative blknos. So this scheme > > > doesn't work for filesystems that don't use this method for indexing > > > their metadata. > > The code is a little ufs specific, but should still work for other FS > > -- it doesn't hurt to write out dirty bufs. > > No, but I'm not sure how it helps either. > > > > Secondly, it doesn't hold a lock while inspecting > > > B_DELWRI. > > > > > It's intentional, see below... > > It's an optimization. > > > > There is also a really weird check to see if the buf's vp > matches the vp > > > we're truncating. This doesn't really make sense since we just > > > pulled this > > > buf off of the dirty block lists for this vnode. > > > > > ..., the buf is not locked, remember :) > > Yes, but you were guaranteed that it wouldn't have migrated to a new vp > even in RELENG_4. The whole thing happens at splbio(). In current > Giant makes that guarantee and now the vnode interlock does as well. The > thing that you aren't guaranteed now is whether or not DELWRI is still > valid. You can be certain that UFS won't have negative blocks locked at > this point though because the vnode lock is held. So this lock should > always succeed anyway. > I thought you were talking about the nbp->b_vp == vp checks. The check for bp->b_vp == vp indeed looks wierd, but the buffer wasn't locked back when the code was first written... -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message