Date: Wed, 30 Dec 2020 14:53:09 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org>, Alan Somers <asomers@freebsd.org>, Kirk McKusick <mckusick@mckusick.com>, Mark Johnston <markj@freebsd.org> Subject: Re: r367672 broke the NFS server Message-ID: <X%2Bx4NSeWI%2Bz5QkP3@kib.kiev.ua> In-Reply-To: <YQXPR0101MB0968DC349AFD081480768028DDD70@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM> References: <YQXPR0101MB0968DC349AFD081480768028DDD70@YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?X%2Bx4NSeWI%2Bz5QkP3>