On Tue, 2012-06-12 at 01:18 +0300, Boaz Harrosh wrote:
> On 06/11/2012 09:59 PM, Myklebust, Trond wrote:
>
> > On Mon, 2012-06-11 at 21:40 +0300, Boaz Harrosh wrote:
> >
> >> And again, please explain why do you want it. What is wrong with the
> >> case we all agree with? ie: "Client can not call LAYOUTRETURN until
> >> all in-flight RPCs return, with or without an error"
> >
> > Who "agreed" to this? This would mean that if the DS goes down, we can't
> > ever send LAYOUTRETURN which is patently wrong.
> >
>
>
> "DS goes down" is under the above "RPC return an error" the error condition
> of an RPC is well defined.
???? Now you have me extremely confused. How does the client distinguish
between ETIMEDOUT-because-DS-went-down and
ETIMEDOUT-but-in-flight-RPCs-will-eventually-succeed-so-please-hold-that-LAYOUTRETURN?
> >From what of my words did you understand that I said
> "we can't ever send a LAYOUTRETURN"
>
> If my English is wrongly worded. Which is perfectly possible. Please correct
> me so I can learn. Did you honestly think that's what I meant?
>
> I meant we all agree, that this case is covered by RFC. That is - no one would
> accuse a client who does that, as violating the RFC.
>
> And again my question. The motivation?
Making fallback-to-MDS work without corrupting your data. Please read up
on multipath-101 and the need for fencing...
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@xxxxxxxxxx
www.netapp.com
��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
