From owner-freebsd-fs@freebsd.org Sun Mar 13 23:31:47 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C126AACE0C8 for ; Sun, 13 Mar 2016 23:31:47 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A50F2CD3 for ; Sun, 13 Mar 2016 23:31:47 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-229-231.lns20.per1.internode.on.net [121.45.229.231]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u2DNVgrd002130 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Sun, 13 Mar 2016 16:31:45 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: Unstable NFS on recent CURRENT To: freebsd-fs@freebsd.org References: <3DAB3639-8FB8-43D3-9517-94D46EDEC19E@gromit.dlib.vt.edu> <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> <2136530467.13386220.1457658490896.JavaMail.zimbra@uoguelph.ca> <56E22455.3040402@quorum.net> From: Julian Elischer Message-ID: <56E5F858.2000407@freebsd.org> Date: Mon, 14 Mar 2016 07:31:36 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56E22455.3040402@quorum.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2016 23:31:48 -0000 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 >>> wrote: >>> >>>> Paul Mather wrote: >>>>> On Mar 8, 2016, at 7:49 PM, Rick Macklem >>>>> wrote: >>>>> >>>>>> Paul Mather wrote: >>>>>>> On Mar 7, 2016, at 9:55 PM, Rick Macklem >>>>>>> wrote: >>>>>>> >>>>>>>> Paul Mather (forwarded by Ronald Klop) wrote: >>>>>>>>> On Sun, 06 Mar 2016 02:57:03 +0100, Paul Mather >>>>>>>>> >>>>>>>>> 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" >