Subject: Re: File system suspension -- new API
To: Pavel Cahyna <pavel@netbsd.org>
From: Juergen Hannken-Illjes <hannken@eis.cs.tu-bs.de>
List: tech-kern
Date: 12/31/2006 11:46:27
On Sun, Dec 31, 2006 at 10:34:03AM +0000, Pavel Cahyna wrote:
> On Sun, Dec 31, 2006 at 11:23:26AM +0100, Juergen Hannken-Illjes wrote:
> > On Sun, Dec 31, 2006 at 11:12:52AM +0100, Pavel Cahyna wrote:
> > > On Fri, Dec 29, 2006 at 04:34:45PM +0100, Juergen Hannken-Illjes wrote:
> > > > +/*
> > > > + * Lock the node.
> > > > + */
> > > > +int
> > > > +ufs_lock(void *v)
> > > > +{
> > > > +	struct vop_lock_args /* {
> > > > +		struct vnode *a_vp;
> > > > +		int a_flags;
> > > > +	} */ *ap = v;
> > > > +	struct vnode *vp = ap->a_vp;
> > > > +	struct mount *mp = vp->v_mount;
> > > > +
> > > > +	/*
> > > > +	 * Fake lock during file system suspension.
> > > > +	 */
> > > > +	if ((vp->v_type == VREG || vp->v_type == VDIR) &&
> > > > +	    fstrans_is_owner(mp) &&
> > > > +	    fstrans_getstate(mp) == fstrans_suspending) {
> > > > +		if ((ap->a_flags & LK_INTERLOCK) != 0)
> > > > +			simple_unlock(&vp->v_interlock);
> > > > +		return 0;
> > > 
> > > How is safe to "fake" a lock? If the caller wants to lock something, it
> > > probably does not expect the lock to be "faked".
> > 
> > Caller here is the thread running the suspension (fstrans_is_owner(mp)) while
> > it is preparing the suspension (fstrans_getstate(mp) == fstrans_suspending).
> > This is only the call to ffs_sync() in ffs_suspendctl().
> 
> But how do you prevent ffs_sync from seeing inconsistent state?

By taking care :-) During suspension most operations are blocked.  We only have
to care about those taking lazy locks.

> > ffs_sync() will release all locks it got so we will not break other locks.
> > 
> > > Why is it needed at all?
> > 
> > ffs_sync() and all operations it calls depend on locks. It would become an
> > ugly maze if we converted all these places to ignore locks while suspending.
> 
> Why should it ignore lock while suspending instead of taking them
> normally?

As we cannot add fstrans_start() to xxx_lock() not ignoring locks will
quickly deadlock.

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