On Sat, 27 Aug 2022, John Stoffel wrote: > >>>>> "NeilBrown" == NeilBrown <neilb@xxxxxxx> writes: > > NeilBrown> NFS can easily support parallel updates as the locking is done on the > NeilBrown> server, so this patch enables parallel updates for NFS. > > Just curious, how is this handled if I have a server with an EXT# > filesystem which is exported via NFS to multiple clients. If those > NFS clients are doing lots of changes in a single directory, I can see > how the NFS server handles that, but what about if at the same time > someone does multiple changes on the server in that EXT# behind the > NFSd's back, how are the conflicts handled? Currently, an exclusive lock is taken by the VFS or NFSD before any create request gets the the EXT# filesystem. That doesn't change (yet). When multiple NFS clients try the create files in a directory, the nfsd threads handling those requests will be serialized by the exclusive lock. Before the patch, if there were multiple threads on a single NFS client, then they are all serialized on the client, and then again on the server. With my patch, the threads on the one client are NOT serialized, but once the requests get to the server they will be. So an exclusive lock is only held of a smaller part of the total time. > > It would seem that this all really needs to purely happen at the VFS > layer, but I'm probably missing something. Serialization has to happen somewhere. It doesn't have to be at the VFS layer. Doing locking at the VFS layer is easy and slow. Doing it deep in the filesystem is difficult and fast. This exercise is really just pushing locking deeper into the filesystem. > > I ask this because my home server exports /home to a couple of other > systems via NFS, but I still work in /home on the server. > Thanks, NeilBrown
