Check out the new USENIX Web site. next up previous
Next: New flag returned by Up: NetBSD vfs changes Previous: Most file systems do

New vnode lock location and chaining

 One change made in how vnodes are locked was to implement vnode lock chaining similar to what Heidemann described in [2]. After this change, each vnode contains a pointer to a lock structure which exports the lock structure used for this vnode. If this pointer is non-null, a layered file system will directly access this lock structure for locking and unlocking the layered vnode. If this pointer is null, the layered file system will call the underlying file system's lock and unlock routines when needed, and will maintain a private lock on its vnode. As described in the preceding section, all leaf file systems other than NFS now do locking, and thus export a lock structure. Once NFS has been fixed, the only file systems which should not export a lock structure would be layered file systems which perform fan-out (such as the UNIONfile system) as they need to perform more complicated locking.

As all file systems should be doing locking and exporting a pointer to a lock structure, I decided to add a lock structure to the vnode structure and remove it from all of the leaf file systems' private data. I was concerned about a whole stack of vnodes referring to file system-specific private data, and felt it cleaner for vnodes to refer to memory contained in vnodes. In retrospect (and having completed the change), it now seems wiser to leave the lock structure in the leaf file system's private data and just require the file system be careful about managing the memory it exports in the lock structure pointer in its vnode. This change would improve memory usage in a system with multiple layered file systems by not allocating a lock structure in the layered vnodes which would go unused.

The effect of this change is that a whole stack of vnodes will lock and unlock simultaneously. At first glance this change seems unimportant, as any locking operation can traverse a vnode stack and interact with the underlying leaf file system. The advantage is three-fold. One advantage is conceptual. By having all layers use the same lock structure, the commonality of the stack is reinforced. Secondly, layered nodes do not need to call the underlying file system if the lock structure has been exported - it may directly manipulate it itself. This lack of stack traversal becomes quite advantageous in the case of multiple layered file systems on top of each other.

The third advantage is due to the lock semantics of the lookup operation on ``..''. To avoid deadlock, directories are locked from parent to child, starting with the root vnode. To preserve this when looking up ``..'', the child directory must be unlocked, the parent locked, and the child then re-locked. When looking up ``..'' in a layered file system, with a unified lock, the leaf file system can unlock the entire stack and re-lock it while trying to obtain the parent node. If the locks were not unified and there were separate locks in vnodes stacked above the leaf one, the leaf file system would either need to somehow unlock and re-lock those locks during the lookup of ``..'' or to run the risk of deadlock where one process had the upper lock(s) and not the lower, while another had the lower and not the upper.


next up previous
Next: New flag returned by Up: NetBSD vfs changes Previous: Most file systems do
Bill Studenmund
2000-04-24