--H+4ONPRPur6+Ovig
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 28, 2006 at 04:30:26PM +0200, Juergen Hannken-Illjes wrote:
> On Mon, Jun 26, 2006 at 02:31:44PM -0700, Bill Studenmund wrote:
> >=20
> > How is it difficult to maintain?
> >=20
> > The idea is that we only use transaction locks above the file system if=
 we
> > have a real transaction.
>=20
> Implementing the transaction locks this way leads to this situation:
>=20
> A file system gets quiet.  Now we are sure all its operations are either
> complete or have not started yet.  But we have locks held.  Our next
> step is to sync the current file system state to disk.  None of the
> operations we have (VFS_SYNC and friends) is usable because they will
> deadlock.  So we have to add another VFS operation to sync to disk
> ignoring locks.  Looks ugly and hard to maintain.

What do you mean, "A file system gets quiet" ?

I assume you mean that the file system transaction lock is exclusively=20
held by the syncing or snapshotting routine. At that point, you know that=
=20
there are no operations that will change file system metadata (and none=20
that will change data) in operation. You know this as you wouldn't have=20
the exclusive lock otherwise.

I do not see how VFS_SYNC would not be usable in face of this. Sure,
VFS_SYNC() AS ITS IMPLEMENTED NOW would not work, but I can not fathom a
reason as to why we would leave VFS_SYNC unchanged if we are changing the
locking hierarchy. :-) All a vfs_sync routine'd have to do is grab an
exclusive transaction lock (just like the snapshotting code would do),
then sync away.

All a new VFS_SYNC needs to do is grab the exclusive transaction lock,=20
then sync everything. It can ignore vnode locks due to a consequence of=20
putting transaction locking in each VOP; each VOP's implementation has to=
=20
grab at least a shared transaction lock before it can do anything, so it=20
can't do anything of note without the transaction lock.

By adding the transaction locking, especially in its current state which=20
has a shared and an exclusive mode, we will be changing the locking=20
hierarcy. It seems reasonable to me that we will need to adjust a number=20
of other things too.

The list of things that needs adjusting, though, does not look large.

Take care,

Bill

--H+4ONPRPur6+Ovig
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFEovvjWz+3JHUci9cRApeQAJ99iM50S/n7L8NONpK4XJmvYdA0ngCfcSvo
CNLJWLGcqbx3tcHD2Y1lLzE=
=zXl/
-----END PGP SIGNATURE-----

--H+4ONPRPur6+Ovig--