Date: Thu, 10 Mar 2016 17:50:13 -0800 From: Marc Goroff <marc.goroff@quorum.net> To: <rmacklem@uoguelph.ca> Cc: <freebsd-fs@freebsd.org> Subject: Re: Unstable NFS on recent CURRENT Message-ID: <56E22455.3040402@quorum.net> In-Reply-To: <2136530467.13386220.1457658490896.JavaMail.zimbra@uoguelph.ca> References: <3DAB3639-8FB8-43D3-9517-94D46EDEC19E@gromit.dlib.vt.edu> <op.ydylazgukndu52@ronaldradial.radialsg.local> <1482595660.8940439.1457405756110.JavaMail.zimbra@uoguelph.ca> <08710728-3130-49BE-8BD7-AFE85A31C633@gromit.dlib.vt.edu> <1290552239.10146172.1457484570450.JavaMail.zimbra@uoguelph.ca> <60E8006A-F0A8-4284-839E-882FAD7E6A55@gromit.dlib.vt.edu> <508973676.11871738.1457575196588.JavaMail.zimbra@uoguelph.ca> <BF9757C7-654D-4FAC-97E4-7E8B36C6E4A7@gromit.dlib.vt.edu> <2136530467.13386220.1457658490896.JavaMail.zimbra@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On 3/10/16 5:08 PM, Rick Macklem wrote: > Paul Mather wrote: >> On Mar 9, 2016, at 8:59 PM, Rick Macklem <rmacklem@uoguelph.ca> wrote: >> >>> Paul Mather wrote: >>>> On Mar 8, 2016, at 7:49 PM, Rick Macklem <rmacklem@uoguelph.ca> wrote: >>>> >>>>> Paul Mather wrote: >>>>>> On Mar 7, 2016, at 9:55 PM, Rick Macklem <rmacklem@uoguelph.ca> wrote: >>>>>> >>>>>>> Paul Mather (forwarded by Ronald Klop) wrote: >>>>>>>> On Sun, 06 Mar 2016 02:57:03 +0100, Paul Mather >>>>>>>> <paul@gromit.dlib.vt.edu> >>>>>>>> wrote: >>>>>>>> >>>>>>>> > Well, the first time I proposed "-S" the collective felt it wasn't the appropriate > solution to the "export reload" problem. The second time, the "collective" agreed > that it was ok as a non-default option. (Part of this story was an alternative to > mountd called nfse which did update exports atomically, but it never made it into > FreeBSD.) The only downside to making it a default is that it does change behaviour > and some might consider that a POLA violation. Others would consider it just a bug fix. > There was one report of long delays before exports got updated on a very busy server. > (I have a one line patch that fixes this, but that won't be committed into FreeBSD-current > until April.) > > Now that "-S" has been in FreeBSD for a couple of years, I am planning on asking > the "collective" (I usually post these kind of things on freebsd-fs@) to make it the > default in FreeBSD-current, because this problem seems to crop up fairly frequently. > I will probably post w.r.t. this in April when I can again to svn commits. > > I only recently found out the Poudriere does mounts and causes this problem. > I may also commit a man page update (which can be MFC'd) that mentions if you > are using Poudriere you want this flag. > Having the same thing mentioned in the Poudriere port install might be nice, too. > > Thanks for testing this, rick > I was amazed when I discovered the "-S" option last year and even more amazed that it wasn't the default. The lack of -S caused us enormous problems in our production ZFS environment last year and nearly caused us to abandon FreeBSD altogether. Every time we'd provision a new ZFS file system from the zpool, all our NFS clients would start throwing alerts due to I/O errors! I'm unclear why it would be considered acceptable to have a reload of an exports file cause spurious I/O errors for NFS clients. I'd think such incorrect behavior would be clearly considered a blatant POLA violation. Causing a delay and returning correct data is far superior to incorrectly returning access errors that screw up well behaved applications on NFS clients. NFS is capable of handling network delays. Why choose instead to return invalid I/O errors? IMHO, -S should be the default. I'm unable to think of any good reason for it to be optional and the lack of it as the default behavior has clearly caused lots of needless pain and suffering in the user community. Marc
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56E22455.3040402>