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