> On the other hand, maybe it's time we looked at pushing the locking back
> into the file systems and being more strict about the reference counting, so
> that these kinds of issues don't continue to appear. :-). What do people
> think of the idea?

i'm all for it.

> Some if the issues involved in doing that I know of are..
> 
> o VOP_LOCK and VOP_UNLOCK would need to go away. To make VOP calls you'd
>   only need a reference to the vnode.
> 
> o We'd need a VOP_RWLOCK or VOP_RANGELOCK for concurrent reads/writes.
> 
> o The calls to VOP_LEASE look suspicious, since they are made and then
>   followed by other VOP calls under the same lock. VOP_LEASE doesn't appear
>   to do anything these days though.

> o Lookup currently holds exclusive vnode locks. It causes a lot of single
>   threading and I think we could get a good speedup by avoiding that. My
>   understanding is that's due to the inode/vnode being used to maintain
>   state for whoever's doing the lookup. What other issues are there? Without
>   understanding the code too clearly I imagine that has effects on layered 
>   file systems too.

> Can anyone see other issues? Any other ideas?

nfs server relies on VOP_LOCK in order to perform a few vops atomically.
it can be a problem if you want to push dirop locks into filesystems.
for WRITE, probably VOP_RWLOCK/VOP_RANGELOCK is enough.

YAMAMOTO Takashi