Date: Tue, 4 Mar 2003 15:43:25 -0800 From: "Luoqi Chen" <lchen@briontech.com> To: "Jeff Roberson" <jroberson@chesapeake.net> Cc: <arch@FreeBSD.ORG> Subject: RE: vtruncbuf() Message-ID: <AHEKICEOIHLOGINAFIINGENNCAAA.lchen@briontech.com> In-Reply-To: <20030304010228.P72102-100000@mail.chesapeake.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AHEKICEOIHLOGINAFIINGENNCAAA.lchen>