> 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
