Re: parallel file create rates (+high latency)

["J. Bruce Fields" <bfields@fieldses.org>]

On Wed, Jan 26, 2022 at 11:02:16AM +1100, NeilBrown wrote:
> On Wed, 26 Jan 2022, J. Bruce Fields wrote:
> > On Tue, Jan 25, 2022 at 03:15:42PM -0600, Patrick Goetz wrote:
> > > So the directory is locked while the inode is created, or something
> > > like this, which makes sense.
> > 
> > It accomplishes a number of things, details in
> > https://www.kernel.org/doc/html/latest/filesystems/directory-locking.html
> 
> Just in case anyone is interested, I wrote this a while back:
> 
> http://lists.lustre.org/pipermail/lustre-devel-lustre.org/2018-November/008177.html
> 
> it includes a patch to allow parallel creates/deletes over NFS (and any
> other filesystem which adds support).
> I doubt it still applies, but it wouldn't be hard to make it work if
> anyone was willing to make a strong case that we would benefit from
> this.

Neato.

Removing the need to hold an exclusive lock on the directory across
server round trips seems compelling to me....

I also wonder: why couldn't you fire off the RPC without any locks, then
wait till you get a reply to take locks and update your local cache?

OK, for one thing, calls and replies and server processing could all get
reordered.  We'd need to know what order the server processed operations
in, so we could process replies in the same order.

--b.