Re: Working on vnode sequencing and locking - HEAD will destabilize for a little bit

[rick@xxxxxxxxxxxxxxxxxxxxxxxx]

>    Finally, the vnode locking will be moved out of the kernel layer and
>    into the filesystem layer.  This is again for userland VFS and clustering.
>    It will mean that we do not have to hold a vnode lock across a filesystem
>    operation... we've already seen what that can lead to with NFS when an
>    NFS server goes down.

Good stuff (and long overdue imho). You may not know that I helped Kirk
come up with the original vfs and, even then, argued that the vnode locking
made things too complicated. Since then, it got even more complex, due to
dynamic allocation of vnodes, etc. (The original vfs used a fixed vnode
table allocated at boot. Although primitive, it had the big advantage that
a vp always worked, so you could just check on the vnode's status with it.)

OSF did something similar and changed the directory offset caching etc. to
use a "soft reference". By "soft reference" I mean there was a rev cnt that
was incremented each time the item (directory) changed, which they saved
with the cached ref. When they went to use the cached ref, they just compared
the ref cnt, to see if it was stale. (One of the main reasons for the locks
above the vnode boundary was so that directories could be locked against
changes between lookup and update, so directory offset caching would still
work. The other was related to lookup/rename, which you are already well
aware of:-)

Good luck with it, rick