Subject: Re: LK_SHARED for VFS_VGET/FHTOVP
To: None <email@example.com>
From: YAMAMOTO Takashi <firstname.lastname@example.org>
Date: 05/27/2004 04:43:15
> Specifically with using exclusive locks, I think that the vnode system was
> fine-grained. Perhaps not the best locking (we can get better parallelism,
> perhaps), but correct. By changing things so we need big-lock, we take a
> step back.
what's "the vnode system"?
the vnode interface itsself, or eachfilesystem implementation,
or something else?
> Over the years the vnode interface has gotten a reputation for being
> complicated and troublesome. When I was at NASA, I worked on cleaning lots
> of it up, and among other things we got production-ready layered file
> systems. Part of getting things to work was being an ass about locking,
> and making sure we did locking right in all places. "Right" meant
> documenting what should happen and auditing all the code to match. To go
> back to a comment you made about me believing documentation, I actually
> tried to make sure the code and documentation matched (what I think
> "should" happen). :-)
> By encouraging us to break what documentation we have, we open the door to
> getting back into an untrusted, confusing mess. For instance, new
> developers have to just "know" that it's "ok" to use shared locks for
> reads, but not anything else.
> 2) We don't know how bad things are. Sure, ffs_read() (and lfs_read())
> only call ufs_update(), which is "ok" as long as we have big-lock. But we
> don't _know_ what the other file systems do, and what problems they have;
> we haven't audited the other code. This uncertainty is one of my big
> concerns about things.
have you audited all of our filesystems at some point before Chuck changed
the code to use LK_SHARED?
> Oh, as an aside, I think in your patch you unlock at one point and then
> re-lock with LK_SHARED. I think all you need to do is call VOP_LOCK() with
> LK_DOWNGRADE or something like it - you can downgrade the exclusive lock
> into a shared one. Also, since you have the exclusive lock, you can just
> use VOP_LOCK() as no one will have initiated reclaiming in the mean time.
i think it's bad idea to allow to use arbitrary fancy lockmgr flags