Re: r367672 broke the NFS server

From: Konstantin Belousov <kostikbel_at_gmail.com>
Date: Wed, 30 Dec 2020 14:53:09 +0200
On Wed, Dec 30, 2020 at 02:02:48AM +0000, Rick Macklem wrote:
> Hi,
> 
> Post r367671...
> When multiple files are being created by an NFS client in the same
> directory, the VOP_CREATE()/ufs_create() can fail with ERELOOKUP.
> This results in a EIO return to the NFS client.
> --> This causes "nfsv4 client/server protocol prob err=10026"
>       on the client for NFSv4.0 mounts.
>       --> This explains why this error has been reported by
>             several people lately, although it should "never happen".
> 
> Unfortunately, for the NFS server, the Lookup call is done separately
> and it will not be easy to redo it, given the current NFS code structure.
> 
> Is there another way to deal with the problem r367672 was fixing that
> avoids ufs_create() returning ERELOOKUP?

Idea of the change is to restart the syscall at top level.  So for NFS
server the right approach is to not send a response and also to not
free the request mbuf chain, but to restart processing.

I am sorry I forgot about NFS server when designing this fix, the only
mild excuse I can provide is that the change was quite complicated as is.

I will start looking at the fix.
Received on Wed Dec 30 2020 - 11:53:19 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:26 UTC