pNFS read/write behavior change in 2.6.39
Subsystems (2)
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.
Quoted 6 lines · 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:
Quoted 7 lines
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
Signature · 6 lines
Trond Myklebust Linux NFS client maintainer NetApp [email protected] www.netapp.com
Quoted 12 lines · Trond Myklebust
Quoted 11 lines · 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]; };
Quoted 6 lines
Quoted 2 lines
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.
Quoted 1 line
Trond
Quoted 13 lines · Tigran Mkrtchyan
Quoted 12 lines · Trond Myklebust
Quoted 11 lines · 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]; };
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
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.
Quoted 8 lines
Tigran.
Quoted 1 line
Trond
Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 15 lines · Tigran Mkrtchyan
Quoted 14 lines · Trond Myklebust
Quoted 13 lines · 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.
Quoted 8 lines
Quoted 4 lines
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
Signature · 6 lines
Trond Myklebust Linux NFS client maintainer NetApp [email protected] www.netapp.com