Date: Mon, 22 Jun 2015 14:02:22 -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%2BJhTNS4XYrmrJeQEQh85d0PHkGG7a4Yt3ZL1E8-RLwNxWA1%2BQ@mail.gmail.com> In-Reply-To: <1969046464.61534041.1434897034960.JavaMail.root@uoguelph.ca> References: <CA%2BJhTNTSC-xPVdpUGcQemVMLUwuQB6D8-3d2HD6WjU%2Bjd1SMNQ@mail.gmail.com> <1969046464.61534041.1434897034960.JavaMail.root@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
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%2BJhTNS4XYrmrJeQEQh85d0PHkGG7a4Yt3ZL1E8-RLwNxWA1%2BQ>