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

[alex.burlyga.ietf alex.burlyga.ietf]

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.

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"
>>>