--bp/iNruPH9dso1Pn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Oct 04, 2003 at 03:50:14PM -0700, Chuck Silvers wrote:
> hi,
>=20
> VOP_PUTPAGES() is used for two somewhat different purposes:
>=20
>  (1) to flush and/or invalidate the pages for a given logical range of
>      a vnode.  the higher level operations that use this are fsync(),
>      msync(), truncate(), write() (to flush pages out behind sequential
>      write()s), etc.
>=20
>  (2) to flush and invalidate a given physical page, used by the pagedaemo=
n.
>      this is called via the vnode pager's pgo_put method.

Makes sense.

> the latter usage is the one which wants the uvm_object lock (aka. the
> vnode "interlock" for vnode objects) to be held.  the former usages
> don't really need the lock to be held for themselves, but since the
> interface is used for the latter purpose as well, they take the lock
> just to satisfy the interface constraints.  it would be possible to
> change the pagedaemon's usage so as to not need the lock held either,
> but that's how it was before UBC and I didn't change it when I added
> VOP_{GET,PUT}PAGES as the implementation of pgo_{get,put} for the vnode
> pager.

Ok. That's a lot less scarry than I thought after looking at the (vfs)
code.

Could you please document this? kern/vnode_if.src and=20
miscfs/genfs/layer_vnops.c are two files that really could use this.

Oh, I'm assuming that lockmgr will unlock the interlock if you sleep while=
=20
trying to get a (vnode) lock. If not, then we have a deadlock as vget() &=
=20
friends grab the interlock then grab the vnode lock, while lots of places=
=20
grab the interlock for this use while holding the vnode lock.

> for all the existing layered file systems, data is cached only in the
> underlying vnode, so we're never in case (2) for layerfs vnodes.
> that's why the lock juggling in layer_putpages() is safe.
> if someone were to write a layered fs that tried to cache data in
> layerfs vnodes, they would have to deal with this (as well as a host
> of other cache-coherency issues).

Thanks!

Take care,

Bill

--bp/iNruPH9dso1Pn
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQE/gaWVWz+3JHUci9cRAtg3AJ9xancXp/lp+lfyathm4fWVjVxB8gCgiACK
2PBjn0AbBPdPQ3x//1LJyzg=
=H2JG
-----END PGP SIGNATURE-----

--bp/iNruPH9dso1Pn--