Message-ID: <4DB6D948.3010803@desy.de>
Date: Tue, 26 Apr 2011 16:40:08 +0200
From: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
To: Trond Myklebust <Trond.Myklebust@netapp.com>
CC: NFS list <linux-nfs@vger.kernel.org>, Steve Dickson <SteveD@redhat.com>,
        "J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: pNFS read/write behavior change in 2.6.39
References: <4DB6D0CC.4050601@desy.de> <1303828194.1785.21.camel@lade.trondhjem.org> <4DB6D8C3.1070801@desy.de>
In-Reply-To: <4DB6D8C3.1070801@desy.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Sender: linux-nfs-owner@vger.kernel.org
MIME-Version: 1.0

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