Subject: Re: vn_lock(LK_RETRY) (was: Re: CVS commit: src/sys/miscfs)
To: YAMAMOTO Takashi <firstname.lastname@example.org>
From: Bill Studenmund <email@example.com>
Date: 06/19/2004 16:15:17
Content-Type: text/plain; charset=us-ascii
On Sat, Jun 19, 2004 at 02:19:57PM +0900, YAMAMOTO Takashi wrote:
> > >=20
> > > actually, there's no much differences.
> > > if vn_lock(LK_RETRY) can fail,
> > > all callers should check it and shouldn't unlock the vnode after an e=
> > > it's better to make sure that vn_lock(LK_RETRY) won't fail rather than
> > > letting all callers check error conditions, IMO.
> > Well, then I guess we'll have to disagree. I'm always concerned by what=
> > happens if a routine that "can't fail" realizes it is going to fail. It=
> > either has to do something like panic, or it has to pretend things are =
> > If instead it can fail, it can tell the upper layers that something is=
> > wrong. They can choose to not do anything, but they've been told.
> there's no problem to having a routine that won't fail.
> and there's no problem not to checking its failure.
I agree that there's no problem in having a routine that can't fail, nor=20
ignoring any "error" return value in such a case. I still feel, though,=20
that vn_lock() isn't that routine.
> i can understand your concern, given that vnode lock's implemention is
> somewhat complicated unnecessarily.
> it's better just to simplify it.
Well, I'll be happy to hear your simplification when you propose it. But=20
as I said above, I don't think just making vn_lock() never fail is the=20
Also, I think a lot of the complexity in the vnode system is there to=20
handle the many different issues it is forced to face. I'm always a bit=20
hesitant about changing it, lest we painfully rediscover a corner case the=
code got right before (but not after) a change.
> > Also, consider something like a distributed file system with a lock=20
> > manager (as in a separate server). Say you can't contact the lock manag=
> > Do you really sit there in uninterruptable sleep for ever? Yes, how and=
> > when you decide to give up is something the admin decides (as it should=
> > be). But the scenario shows a reason to have vn_lock(LK_RETRY) fail.
> such a distributed filesystem is broken in design, IMO.
> it's a horrible idea to use vnode locks for remote locking.
Maybe, maybe not. One advantage of our node locking protocol is that the=20
locking is visable to the caller. So the caller can use the lock to=20
perform a sequence of actions atomically.
> btw, please answer my first question.
> are you going to add checks on every vn_lock(LK_RETRY)?
Not at the present time. While I think that would be a good and correct
thing, I do not have the time nor energy to change each occurrence.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----