Re: Optimal NFS mount options to safely allow interrupts and timeouts on newer kernels

[Trond Myklebust <trond.myklebust@primarydata.com>]

On Mar 6, 2014, at 11:45, Chuck Lever <chuck.lever@oracle.com> wrote:

> 
> On Mar 6, 2014, at 11:16 AM, Trond Myklebust <trond.myklebust@primarydata.com> wrote:
> 
>> 
>> On Mar 6, 2014, at 11:13, Chuck Lever <chuck.lever@oracle.com> wrote:
>> 
>>> 
>>> On Mar 6, 2014, at 11:02 AM, Trond Myklebust <trond.myklebust@primarydata.com> wrote:
>>> 
>>>> 
>>>> On Mar 6, 2014, at 10:59, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>> 
>>>>> 
>>>>> On Mar 6, 2014, at 10:33 AM, Trond Myklebust <trond.myklebust@primarydata.com> wrote:
>>>>> 
>>>>>> 
>>>>>> On Mar 6, 2014, at 10:26, Chuck Lever <chuck.lever@oracle.com> wrote:
>>>>>> 
>>>>>>> 
>>>>>>> On Mar 6, 2014, at 7:34 AM, Jim Rees <rees@umich.edu> wrote:
>>>>>>> 
>>>>>>>> Given this is apache, I think if I were doing this I'd use ro,soft,intr,tcp
>>>>>>>> and not try to write anything to nfs.
>>>>>>> 
>>>>>>> I agree. A static web page workload should be read-mostly or read-only. The (small) corruption risk with “ro,soft" is that an interrupted read would cause the client to cache incomplete data.
>>>>>> 
>>>>>> What? How? If that were the case, we would have a blatant read bug. As I read the current code, _any_ error will cause the page to not be marked as up to date.
>>>>> 
>>>>> Agree, the design is sound. But we don’t test this use case very much, so I don’t have 100% confidence that there are no bugs.
>>>> 
>>>> Is that the royal ‘we’, or are you talking on behalf of all the QA departments and testers here? I call bullshit…
>>> 
>>> If you want to differ with my opinion, fine. But your tone is not professional or appropriate for a public forum. You need to start treating all of your colleagues with respect, including me.
>>> 
>>> If anyone else had claimed a testing gap, you would have said “If that were the case, we would have a blatant read bug” and left it at that. But you had to go one needless and provocative step further.
>>> 
>>> Stop bullying me, Trond. I’ve had enough of it.
>> 
>> The stop spreading FUD. That is far from professional too.
> 
> FUD is a marketing term, and implies I had intent to deceive. Really?
> 
> I expressed a technical opinion, with a degree of uncertainty, just like everyone else does. People who ask questions here are free to take our advice or not, based on their own experience. They are adults, they read “IMO” where it is implied.
> 
> It is absolutely your right to say that I’m incorrect, or to clarify something I said. If you have test data that shows "ro,soft,tcp" cannot possibly cause any version of the Linux NFS client to cache corrupt data, show it, without invective. That is an appropriate response to my remark.
> 
> Face it, you over-reacted. Again. Knock it off.
> 

You clearly don’t know what other people are testing with, and you clearly didn’t ask anyone before you started telling users that 'soft' is untested. I happen to know a server vendor for which _all_ internal QA tests are done using the ‘soft’ mount option on the clients. This is done for practical reasons in order to prevent client hangs if the server should panic. I strongly suspect that other QA departments are testing the ’soft' case too.

Acting as if you are an authoritative source on the subject of testing, when you are not and you know that you are not, does constitute intentional deception, yes. …and no, I don’t see anything above to indicate that this was an ‘opinion’ on the subject of what is being tested which is precisely why I called it.

There are good reasons to distrust the ‘soft’ mount option, but lack of testing is not it. The general lack of application support for handling the resulting EIO errors is, however...

_________________________________
Trond Myklebust
Linux NFS client maintainer, PrimaryData
trond.myklebust@primarydata.com