From owner-freebsd-arch Mon Mar 3 22: 7:28 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 88DAE37B401 for ; Mon, 3 Mar 2003 22:07:26 -0800 (PST) Received: from mail.chesapeake.net (chesapeake.net [205.130.220.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC63E43F75 for ; Mon, 3 Mar 2003 22:07:25 -0800 (PST) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.11.6/8.11.6) with ESMTP id h24676159798; Tue, 4 Mar 2003 01:07:06 -0500 (EST) (envelope-from jroberson@chesapeake.net) Date: Tue, 4 Mar 2003 01:07:06 -0500 (EST) From: Jeff Roberson To: Luoqi Chen Cc: arch@FreeBSD.ORG Subject: RE: vtruncbuf() In-Reply-To: Message-ID: <20030304010228.P72102-100000@mail.chesapeake.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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? > > 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 hadn't thought about that until just now. I may just test with that lock moved up and ignore the issue unless some one gives me some compelling reason to do otherwise. > > Comments please? > > > > Thanks, > > Jeff > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message