[nfs][client] - Question about handling of the NFS3_EEXIST error in SYMLINK rpc

[Rick Macklem]

Alex Burlyga wrote:
> Rick,
> 
> I was able to test the patch. Works as expected. With sysctl set to 1
> I can reproduce original issue, setting sysctl to 0 fixes the issue.
> I'll leave running tests over night, but everything looks great.
> 
The patch has been committed to head. I don't know if it will be in 10.2.
That will be up to re at .

rick

> Alex
> 
> On Mon, Jun 22, 2015 at 2:02 PM, alex.burlyga.ietf alex.burlyga.ietf
> <alex.burlyga.ietf at gmail.com> wrote:
> > Rick,
> >
> > Thank you for a quick turn around, see answers inline:
> >
> > On Sun, Jun 21, 2015 at 7:30 AM, Rick Macklem <rmacklem at uoguelph.ca> wrote:
> >> Alex Burlyga wrote:
> >>> Hi,
> >>>
> >>> NFS client code in nfsrpc_symlink() masks server returned NFS3_EEXIST
> >>> error
> >>> code
> >>> by returning 0 to the upper layers. I'm assuming this was an attempt
> >>> to
> >>> work around
> >>> some server's broken replay cache out there, however, it breaks a
> >>> more
> >>> common
> >>> case where server is returning EEXIST for legitimate reason and
> >>> application
> >>> is expecting this error code and equipped to deal with it.
> >>>
> >>> To fix it I see three ways of doing this:
> >>>  * Remove offending code
> >>>  * Make it optional, sysctl?
> >>>  * On NFS3_EEXIST send READLINK rpc to make sure symlink content is
> >>>  right
> >>>
> >>> Which of the ways will maximize the chances of getting this fix
> >>> upstream?
> >>>
> >> I've attached a patch for testing/review that does essentially #2.
> >> It has no effect on trivial tests, since the syscall does a Lookup
> >> before trying to create the symlink and fails with EEXIST.
> >> Do you have a case where competing clients are trying to create
> >> the symlink or something like that, which runs into this?
> >
> > That's exactly failing test case we are running into.
> >>
> >> Please test the attached patch, since I don't know how to do that, rick
> > Great! I'll test it. I was leaning towards option 3 for SYMLINK and
> > option 2 for MKDIR.
> > This will work. Thanks for taking your time to generate the patch!
> >
> >>
> >>> One more point, old client circa FreeBSD 7.0 does not exhibit this
> >>> problem.
> >>>
> >>> Alex
> >>> _______________________________________________
> >>> freebsd-fs at freebsd.org mailing list
> >>> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> >>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
> >>>
>