Subject: Re: vclean: vnode locking procedure change #1a to suport stacked fs's
To: Konrad Schroder <>
From: Bill Studenmund <>
List: tech-kern
Date: 06/07/1999 10:23:28
On Fri, 4 Jun 1999, Konrad Schroder wrote:

> > I'm not really sure what from-below VOPs make sense. :-)
> Well ... I think it's fairly obvious that most people can live without any
> of the functionality I'm suggesting :^) it just seems to me that it could
> be useful in some cases.
> How about remove/rmdir, as they affect the file metadata (the implicit bit
> "file exists in the fs namespace"). This really isn't a very important
> problem, but can cause user confusion if it is visible to them (PR #4315).

Hmmm. I'm not sure what the best thing to do here is. Probably some sort
of for-stacked-fs VOP (a from-below one) would be best. Also one thing we
might need/want would be a bit in the vnode flags which says "vrele/vput
me to the FRONT of the free list" or "vclean me immediatly" so that an
upper-layer vnode will get reclaimed (and thus drop the ref on the lower
node) more quickly. I bet this was the case where you thought stacked
nodes should be cleaned quicker, and I agree.

> If the upper layer is caching other metadata --- say it provides ACLs or
> some other permission-modifying service sufficiently more complex than
> UMAPFS that it has to store modifiable data somewhere --- then it might
> want to know if the underlying file's permissions have been modified; so
> add setattr to the list.

I think if you can get at the underlying files, under an ACL layer, you
have real security problems. An ACL layer would need to be an in-place
layer - both source and mount points are the same. That way you can't get
at the filestore w/o going through the ACL layer.

> If the upper layer is caching file data --- say an encryption layer --- it
> would be unfortunate if the lower vnode were truncated, and the upper
> layer didn't notice and wrote the cached data.  Not necessarily an error,
> but an unnecessary and undesirable artifact.  So truncate, too.

I think we are a ways off from supporting data caching in upper fs layers.
:-( I'd think in general if you want to truncate pages, the lower layer
would have to be caching them at the time, so it'd have to get them back
from the upper layer before truncating.

> Finally, you might want a general purpose file watcher for a small number
> of files, and be unwilling to put a stacked filesystem over their
> containing directories...NT's file event auditing comes to mind.  For this
> you'd need to be passed every operation that someone might want to audit,
> which would probably include everything except VOP_PRINT.
> Again not functionality that most people want/need, nor certainly anything
> that is necessary for the stacked filesystems we currently have.  But
> possibly useful.

Take care,