--UHN/qo2QbUvPLonB
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=
=20
> > "gate" you spoke of originally, the thing that makes us atomic w.r.t. a=
=20
> > snapshot), then it's not a problem. We just have the read and write cod=
e=20
> > 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
missed.

> > Not taking a lock is fine, releasing someone else's lock and retaking o=
ne=20
> > is a problem.
> >=20
> > Such a change would limit our exposure to cases where someone is trying=
 to=20
> > make a transaction that involves writing to or reading from a fifo. If =
you=20
> > try to do that, you get what you get.
>=20
> Both specfs and fifofs need special care because they are no real file sy=
stems.
> 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=
saction
> lock.  The real operations (as long as they dont go to disk devices) cann=
ot
> 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=
=20
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=
=20
transaction lock.

> We could move the special treatment of fifofs up by something like
>=20
>     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.
>=20
> To me it looks better to put it into fifofs the same way its put into spe=
cfs.
>=20
> And I'm still looking for a better name instead of vn_hold/vn_release ...

vn_trans_lock()/vn_trans_unlock().

What do other OSs do?

Take care,

Bill

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

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFEoA7PWz+3JHUci9cRAtSUAJ9Q8vdXBcf0fS1eOcZ7BQAGuzAEzACfUIzE
cAO1mzsg6EduDgbHSXpvx8U=
=3jIK
-----END PGP SIGNATURE-----

--UHN/qo2QbUvPLonB--