Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 4 Mar 2003 01:07:06 -0500 (EST)
From:      Jeff Roberson <jroberson@chesapeake.net>
To:        Luoqi Chen <lchen@briontech.com>
Cc:        arch@FreeBSD.ORG
Subject:   RE: vtruncbuf()
Message-ID:  <20030304010228.P72102-100000@mail.chesapeake.net>
In-Reply-To: <AHEKICEOIHLOGINAFIINOENMCAAA.lchen@briontech.com>

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?

> > 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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030304010228.P72102-100000>