Date: Mon, 14 Mar 2016 07:31:36 +0800 From: Julian Elischer <julian@freebsd.org> To: freebsd-fs@freebsd.org Subject: Re: Unstable NFS on recent CURRENT Message-ID: <56E5F858.2000407@freebsd.org> In-Reply-To: <56E22455.3040402@quorum.net> 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> <56E22455.3040402@quorum.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/03/2016 9:50 AM, Marc Goroff wrote: > > 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. > I agree with this... ZFS has change things.. with ZFS fielsystems coming and going, we need this Rick, if you send me the a patch, I'm looking for a commit to stave off the grim (commit bit) reaper :-) > Marc > > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://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?56E5F858.2000407>