Date: Fri, 3 Jul 2015 18:01:13 -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%2BJhTNQPeBj5BAVz-QrpzdQQyTYji%2BsGdfcGMCyKzgSGQrfMLg@mail.gmail.com> In-Reply-To: <797076669.3619739.1435886554308.JavaMail.zimbra@uoguelph.ca> References: <CA%2BJhTNTSC-xPVdpUGcQemVMLUwuQB6D8-3d2HD6WjU%2Bjd1SMNQ@mail.gmail.com> <1969046464.61534041.1434897034960.JavaMail.root@uoguelph.ca> <CA%2BJhTNS4XYrmrJeQEQh85d0PHkGG7a4Yt3ZL1E8-RLwNxWA1%2BQ@mail.gmail.com> <CA%2BJhTNSVu1L6e0DhjcmBHjpm7wKSfxT7tvD4jn_dQ8zgQKaLSA@mail.gmail.com> <797076669.3619739.1435886554308.JavaMail.zimbra@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
Great, hopefully this will get picked up for 10.2 so we can pick it up from upstream. Alex On Thu, Jul 2, 2015 at 6:22 PM, Rick Macklem <rmacklem@uoguelph.ca> wrote: > 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@. > > rick > >> 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%2BJhTNQPeBj5BAVz-QrpzdQQyTYji%2BsGdfcGMCyKzgSGQrfMLg>