--hQiwHBbRI9kgIhsi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 19, 2004 at 01:54:00PM +0900, YAMAMOTO Takashi wrote:
> hi,
>=20
> > Module Name:	src
> > Committed By:	hannken
> > Date:		Tue May 25 14:55:47 UTC 2004
>=20
> > - Add function transferlockers to transfer any waiting processes from
> >   one lock to another.
>=20
> i strongly object against adding a new fancy lockmgr feature.
> in this case, it should be handled in an ffs-internal manner.

Well, what else should he have done? He has to move the sleepers from one
lock to another, given what he's doing (I looked hard at this at the time
it was added). At the time he decides to do the transfer, the sleepers are
ALREADY asleep on a lock. So there's no ffs-internal way to handle this;=20
the sleepers are already outside of the ffs code.

Given the lock semantics, that all snapshot uses get locked out at the=20
same time, this lock migration is the only option.

What happens is that the second or subsequent snapshot on a file system=20
has its vnode lock folded to the mountpoint-specific snapshot lock. Hmm, I=
=20
think the first one may get that behavior too, I'll need to go back and=20
look; something will need to be done so that releasing the first snapshot=
=20
doesn't hose all the others.

I was a bit surprised when this code was added, as I never considered=20
v_vnlock to be changable once a vnode was in use. However there are=20
reference checks before this call which ensure that it will never get=20
executed for a node under a layered file system (that and the fact that I=
=20
made VFS_SNAPSHOT() an explicit error for layered file systems).

So why do you object? What is wrong with using the locking we have?

> (sorry for objecting later...)

No problem.

Take care,

Bill

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

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

iD8DBQFA1Mv0Wz+3JHUci9cRAhN5AJ9IpX9t5h7gOiC12xQSm/6SJ0PnyACeKJ/D
2w91alz3cpIAfndSjkrIZ9s=
=FqmL
-----END PGP SIGNATURE-----

--hQiwHBbRI9kgIhsi--