Subject: Re: Redoing file system suspension API (update)
To: Bill Studenmund <>
From: Bill Studenmund <>
List: tech-kern
Date: 06/26/2006 09:43:59
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 24, 2006 at 11:05:04AM +0200, Juergen Hannken-Illjes wrote:
> On Fri, Jun 23, 2006 at 05:14:00PM -0700, Bill Studenmund wrote:
> >=20
> > Especially if we go with the idea of having the file system grab and=20
> > release the mountpoint-transaction-lock (the current incarnation of the=
> > "gate" you spoke of originally, the thing that makes us atomic w.r.t. a=
> > snapshot), then it's not a problem. We just have the read and write cod=
> > in fifofs not take the transaction lock, and we're fine.

I'm sorry, but this is an important point. I have the feeling it was=20

> > Not taking a lock is fine, releasing someone else's lock and retaking o=
> > is a problem.
> >=20
> > Such a change would limit our exposure to cases where someone is trying=
> > make a transaction that involves writing to or reading from a fifo. If =
> > try to do that, you get what you get.
> Both specfs and fifofs need special care because they are no real file sy=
> Their vnodes live in real file systems that may update meta data before or
> after they call operations on specfs/fifofs.  These updates need the tran=
> lock.  The real operations (as long as they dont go to disk devices) cann=
> keep this lock because they may sleep forever waiting for data.

How many transactions, other than an actual write or read, will write or=20
read a fifo?

Thus if we move the transaction/snapshot logging into the read or write
call, we have fifofs and specfs skip that step, and we're fine.

Reads and writes do not actually update the on-disk metadata. They set=20
flags in the vnode indicating an update is needed, and an operation later=
comes along and shoves in times & writes the node to disk. The important=20
point is that setting the "update request" flag doesn't interfeer with the=
transaction lock.

> We could move the special treatment of fifofs up by something like
>     if (vp->v_type !=3D VFIFO)
> 	vn_hold(vp);
>     VOP_XXX(vp, ...);
>     if (vp->v_type !=3D VFIFO)
> 	vn_release(vp);

Gool lord no! It'd be better to break transaction semantics than do this.

> We cannot do this for for VCHR/VBLK devices because they may be tapes that
> also need this special treatment on VBLK devices.
> To me it looks better to put it into fifofs the same way its put into spe=
> And I'm still looking for a better name instead of vn_hold/vn_release ...


What do other OSs do?

Take care,


Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.2.3 (NetBSD)