On Mar 6, 2014, at 11:13, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: > > On Mar 6, 2014, at 11:02 AM, Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> wrote: > >> >> On Mar 6, 2014, at 10:59, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >> >>> >>> On Mar 6, 2014, at 10:33 AM, Trond Myklebust <trond.myklebust@xxxxxxxxxxxxxxx> wrote: >>> >>>> >>>> On Mar 6, 2014, at 10:26, Chuck Lever <chuck.lever@xxxxxxxxxx> wrote: >>>> >>>>> >>>>> On Mar 6, 2014, at 7:34 AM, Jim Rees <rees@xxxxxxxxx> 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... _________________________________ Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
