Subject: Re: CVS commit: src
To: None <email@example.com>
From: =?iso-8859-1?Q?J=FCrgen?= Hannken-Illjes <firstname.lastname@example.org>
Date: 06/20/2004 12:04:47
On Sun, Jun 20, 2004 at 02:15:24PM +0900, YAMAMOTO Takashi wrote:
> > > > Module Name: src
> > > > Committed By: hannken
> > > > Date: Tue May 25 14:55:47 UTC 2004
> > >
> > > > - Add function transferlockers to transfer any waiting processes from
> > > > one lock to another.
> > >
> > > 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;
> > the sleepers are already outside of the ffs code.
> i think that having some tricks in VOP_LOCK/UNLOCK/ISLOCKED is enough.
> (in addition to stopping exporting v_vnlock, of course.)
What "tricks" could merge locks A and B into B?
The reason all snapshot vnodes on a file system share a single lock is (from
FreeBSD CVS log of ffs_snapshot):
date: 2002/10/16 00:19:23; author: mckusick; state: Exp; lines: +91 -42
Change locking so that all snapshots on a particular filesystem share
a common lock. This change avoids a deadlock between snapshots when
separate requests cause them to deadlock checking each other for a
need to copy blocks that are close enough together that they fall
into the same indirect block.
Jürgen Hannken-Illjes - email@example.com