On Sat, 16 Mar 2002, Bill Studenmund wrote:

> On 17 Mar 2002, enami tsugutomo wrote:
>
> > "Jeremy C. Reed" <reed@reedmedia.net> writes:
> >
> > > Or can someone provide a patch to workaround the nullfs not reclaiming
> > > free space problem for 1.5.3_ALPHA?
> >
> > I've just cooked the patch for -release branch.  This includes
> > actually two workaround (reclaiming storage is delayed and device
> > close routine won't called due to layerfs cache).
>
> Don't forget overlay and umap, and it looks fine.

I take that back. The part about removing is fine (other than the fact I
think it should be vrecycle, not vgone), but I'm not sure about the device
stuff.

I'm confused. How does the layer cache keep the underlying close routine
from being called? The layer cache means essentially that the lower
_inactivate() routine is called later than it would be otherwise. So I
looked at ufs_inactivate as a common one to deal with. It doesn't call
vop_close. So how is the cache doing this?

I suspect you fixed the wrong bug. What was the problem case, so I can see
if I can reproduce it.

What I can see being a problem is that spec_close does some fancy cleanup
if we are the session leader, which we don't do in the layering. We
probably should move some of that fancy counting up.

Take care,

Bill