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)