Logging a modification intent against an inode wouldn't require a new internal inode lock; AFAICT all it requires is exclusivity against lookup so that lookup can find new/unlinked dirents that have been logged but not yet added to or removed from the physical directory blocks. We can do that by inserting the VFS inode into cache in the foreground operation and leaving I_NEW set on create. We can do a similar thing with unlink (I_WILL_FREE?) to make the VFS inode invisible to new lookups before the unlink has actually been processed. In this way, we can push the actual processing into background work queues without actually changing how the namespace behaves from a user perspective... We -might- be able to do all these operations under a shared VFS lock, but it is not necessary to have a shared VFS lock to enable such a async processing model. If the performance gains for the NFS client come from allowing concurrent processing of individual synchronous operations, then we really need to consider if there are other methods of hiding synchronous operation latency that might be more applicable to more filesystems and high performance user interfaces... -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
