Date: Thu, 2 Jul 2015 15:59:29 -0700 From: "alex.burlyga.ietf alex.burlyga.ietf" <alex.burlyga.ietf@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-fs <freebsd-fs@freebsd.org> Subject: Re: [nfs][client] - Question about handling of the NFS3_EEXIST error in SYMLINK rpc Message-ID: <CA%2BJhTNSVu1L6e0DhjcmBHjpm7wKSfxT7tvD4jn_dQ8zgQKaLSA@mail.gmail.com> In-Reply-To: <CA%2BJhTNS4XYrmrJeQEQh85d0PHkGG7a4Yt3ZL1E8-RLwNxWA1%2BQ@mail.gmail.com> References: <CA%2BJhTNTSC-xPVdpUGcQemVMLUwuQB6D8-3d2HD6WjU%2Bjd1SMNQ@mail.gmail.com> <1969046464.61534041.1434897034960.JavaMail.root@uoguelph.ca> <CA%2BJhTNS4XYrmrJeQEQh85d0PHkGG7a4Yt3ZL1E8-RLwNxWA1%2BQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-fs >>> To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >>>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BJhTNSVu1L6e0DhjcmBHjpm7wKSfxT7tvD4jn_dQ8zgQKaLSA>