Subject: Re: Redoing file system suspension API (update)
To: Bill Studenmund <wrstuden@netbsd.org>
From: Juergen Hannken-Illjes <hannken@eis.cs.tu-bs.de>
List: tech-kern
Date: 06/23/2006 21:02:33
On Fri, Jun 23, 2006 at 10:26:00AM -0700, Bill Studenmund wrote:
> On Thu, Jun 22, 2006 at 05:55:52PM +0200, Juergen Hannken-Illjes wrote:
> > On Wed, Jun 21, 2006 at 02:24:53PM -0700, Bill Studenmund wrote:
> > > On Wed, Jun 21, 2006 at 01:34:38PM +0200, Juergen Hannken-Illjes wrote:
> > > > On Wed, Jun 21, 2006 at 08:02:56PM +0900, YAMAMOTO Takashi wrote:
> > [snip]
> > > > > well, i think neither syscalls or individual VOPs are appropriate
> > > > > for your purpose.  what you need is the intermediate.  ie. a set of VOPs.
> > > 
> > > Yeah, this is what I'm thinking we should do.
> > 
> > What if we add "critical regions" to vnodes?  This could look like
> > 
> >     vn_hold(vp, V_WAIT);
> >     VOP_XXX(...);
> >     VOP_XXX(...);
> >     ...
> >     vn_release(vp);
> > 
> > or
> > 
> >     NDINIT(..., ... | HOLDLEAF, ...);
> >     if (namei(...) == 0) {
> > 	VOP_XXX(nd->ni_vp, ...);
> > 	VOP_XXX(nd->ni_vp, ...);
> > 	...
> > 	vn_release(vp);
> >     }
> > 
> > vn_hold() would wait until suspension is over and the vnode is not held,
> > then set a flag VHOLD and increment a hold counter in vp->v_mount.
> 
> This is kinda what we are doing now, and what I think is a good idea.
> 
> The name, however, is bad. We already have a "hold" facility on vnodes, 
> which is where writes to backing store keep a vnode in memory even if it's 
> not otherwise being actively used. So use different names. :-)

Will do.

> > vfs_suspend() would stop further vn_hold(), wait until the hold counter
> > drops to zero, suspend and then allow vn_hold() again.
> > 
> > For specfs/fifofs we could
> > 
> >     need_hold = (vp->v_flags & VHOLD);
> >     if (need_hold)
> > 	vn_release(vp);
> >     ... device operation that may sleep long ...
> >     if (need_hold)
> > 	vn_hold(vp, V_WAIT);
> 
> I don't see why fifofs should get special treatment.

It has long sleeps on "fifor" and "fifow" and its so_receive() and so_send()
calls may also go to long sleep.

-- 
Juergen Hannken-Illjes - hannken@eis.cs.tu-bs.de - TU Braunschweig (Germany)