To: None <>
From: YAMAMOTO Takashi <>
List: tech-kern
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.

documented where?

> 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