pNFS read/write behavior change in 2.6.39

pNFS read/write behavior change in 2.6.39

[Tigran Mkrtchyan]

I run 2.6.39-0.rc4.git2.0 build for fedora-16 build by redhat.
Probably Steve and Bruce can comment on the patch set.

My observation is that state id provided by client on read to
DS dit not contain correct stateid:

struct stateid4 {
         uint32_t        seqid;
         opaque          other[12];
};

The seqid equals to zero when client send it to DS which is not the
value returned on OPEN.

The problem is not observed with

ae7441fa120ff35b40b4dab167645907a9da1dab

from Bennys tree  as well as with frdora 15 builds from Steve.
With
Regards,
    Tigran.

Re: pNFS read/write behavior change in 2.6.39

[Trond Myklebust]

On Tue, 2011-04-26 at 16:03 +0200, Tigran Mkrtchyan wrote:
> I run 2.6.39-0.rc4.git2.0 build for fedora-16 build by redhat.
> Probably Steve and Bruce can comment on the patch set.
> 
> My observation is that state id provided by client on read to
> DS dit not contain correct stateid:
> 
> struct stateid4 {
>          uint32_t        seqid;
>          opaque          other[12];
> };
> 
> The seqid equals to zero when client send it to DS which is not the
> value returned on OPEN.

Why do you think this is a bug? Section 8.2.2 of RFC5661 not only allows
this behaviour, it actually suggests it is appropriate for READ and
WRITE since it means that the server isn't forced to constantly check
the seqid value.

Trond
-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com

Re: pNFS read/write behavior change in 2.6.39

[Tigran Mkrtchyan]

On 04/26/2011 04:29 PM, Trond Myklebust wrote:
> On Tue, 2011-04-26 at 16:03 +0200, Tigran Mkrtchyan wrote:
>> I run 2.6.39-0.rc4.git2.0 build for fedora-16 build by redhat.
>> Probably Steve and Bruce can comment on the patch set.
>>
>> My observation is that state id provided by client on read to
>> DS dit not contain correct stateid:
>>
>> struct stateid4 {
>>           uint32_t        seqid;
>>           opaque          other[12];
>> };
>>
>> The seqid equals to zero when client send it to DS which is not the
>> value returned on OPEN.
> Why do you think this is a bug? Section 8.2.2 of RFC5661 not only allows
> this behaviour, it actually suggests it is appropriate for READ and
> WRITE since it means that the server isn't forced to constantly check
> the seqid value.
Well, It's not a bug, but it's not the behavior we was testing at 
Connectathon.
My expectation was that during interoperability testing we catch such 
changes.

Tigran.
> Trond

Re: pNFS read/write behavior change in 2.6.39

[Tigran Mkrtchyan]

On 04/26/2011 04:37 PM, Tigran Mkrtchyan wrote:
> On 04/26/2011 04:29 PM, Trond Myklebust wrote:
>> On Tue, 2011-04-26 at 16:03 +0200, Tigran Mkrtchyan wrote:
>>> I run 2.6.39-0.rc4.git2.0 build for fedora-16 build by redhat.
>>> Probably Steve and Bruce can comment on the patch set.
>>>
>>> My observation is that state id provided by client on read to
>>> DS dit not contain correct stateid:
>>>
>>> struct stateid4 {
>>>           uint32_t        seqid;
>>>           opaque          other[12];
>>> };
>>>
>>> The seqid equals to zero when client send it to DS which is not the
>>> value returned on OPEN.
>> Why do you think this is a bug? Section 8.2.2 of RFC5661 not only allows
>> this behaviour, it actually suggests it is appropriate for READ and
>> WRITE since it means that the server isn't forced to constantly check
>> the seqid value.
> Well, It's not a bug, but it's not the behavior we was testing at 
> Connectathon.
> My expectation was that during interoperability testing we catch such 
> changes.

Nevertheless, that can be failure on my side as I have a different  DS 
at Connectathon and
in the production.
>
> Tigran.
>> Trond
>
> -- 
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pNFS read/write behavior change in 2.6.39

[Trond Myklebust]

On Tue, 2011-04-26 at 16:37 +0200, Tigran Mkrtchyan wrote:
> On 04/26/2011 04:29 PM, Trond Myklebust wrote:
> > On Tue, 2011-04-26 at 16:03 +0200, Tigran Mkrtchyan wrote:
> >> I run 2.6.39-0.rc4.git2.0 build for fedora-16 build by redhat.
> >> Probably Steve and Bruce can comment on the patch set.
> >>
> >> My observation is that state id provided by client on read to
> >> DS dit not contain correct stateid:
> >>
> >> struct stateid4 {
> >>           uint32_t        seqid;
> >>           opaque          other[12];
> >> };
> >>
> >> The seqid equals to zero when client send it to DS which is not the
> >> value returned on OPEN.
> > Why do you think this is a bug? Section 8.2.2 of RFC5661 not only allows
> > this behaviour, it actually suggests it is appropriate for READ and
> > WRITE since it means that the server isn't forced to constantly check
> > the seqid value.
> Well, It's not a bug, but it's not the behavior we was testing at 
> Connectathon.
> My expectation was that during interoperability testing we catch such 
> changes.

My expectation is that everyone is coding to the spec, and not to
specific client or server behaviours. The main goal of interoperability
testing should be to discover deviations from the spec and/or incomplete
implementations.

Cheers
  Trond

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
Trond.Myklebust@netapp.com
www.netapp.com