Unstable NFS on recent CURRENT
Julian Elischer
julian at freebsd.org
Sun Mar 13 23:31:48 UTC 2016
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 at uoguelph.ca>
>>> wrote:
>>>
>>>> Paul Mather wrote:
>>>>> On Mar 8, 2016, at 7:49 PM, Rick Macklem <rmacklem at uoguelph.ca>
>>>>> wrote:
>>>>>
>>>>>> Paul Mather wrote:
>>>>>>> On Mar 7, 2016, at 9:55 PM, Rick Macklem
>>>>>>> <rmacklem at uoguelph.ca> wrote:
>>>>>>>
>>>>>>>> Paul Mather (forwarded by Ronald Klop) wrote:
>>>>>>>>> On Sun, 06 Mar 2016 02:57:03 +0100, Paul Mather
>>>>>>>>> <paul at 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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
>
More information about the freebsd-fs
mailing list