|
»
« Return to Thread: layout return - final update ?
Re: layout return - final update ?
by Benny Halevy-4
::
Rate this Message:
On 2012-03-02 15:52, david.noveck@... wrote:
>> This means that the client MUST use the layout stateid it has in hand as long as
>> it keeps this state, even if it CLOSEd the filehandle and reOPENed it.
>> Otherwise, if it sends a LAYOUTGET using the new open_stateid, it will
>> implicitly return its previous layout state, as per our forgetful client
>> model and the semantics discussed for LAYOUTGET using non-layout stateid.
>
> Good catch.
>
> Is this going to be an issue for existing clients, who might not be expecting
> this to happen, given that RFC5661 didn't say this explicitly?
The errata might be clarifying RFC5661, based on the following text.
Existing clients should expect this behavior anyway, the gist of the errata
is about serializing the LAYOUTGETs wityh non-layout stateid, no their
expected semantics.
12.5.2. Getting a Layout
In order to get a layout, the client must first have opened the file
via the OPEN operation. When a client has no layout on a file, it
MUST present an open stateid, a delegation stateid, or a byte-range
lock stateid in the loga_stateid argument. A successful LAYOUTGET
result includes a layout stateid. The first successful LAYOUTGET
processed by the server using a non-layout stateid as an argument
MUST have the "seqid" field of the layout stateid in the response set
to one. Thereafter, the client MUST use a layout stateid (see
Section 12.5.3) on future invocations of LAYOUTGET on the file, and
the "seqid" MUST NOT be set to zero. Once the layout has been
retrieved, it can be held across multiple OPEN and CLOSE sequences.
Therefore, a client may hold a layout for a file that is not
currently open by any user on the client. This allows for the
caching of layouts beyond CLOSE.
_______________________________________________
nfsv4 mailing list
nfsv4@...
https://www.ietf.org/mailman/listinfo/nfsv4
>> This means that the client MUST use the layout stateid it has in hand as long as
>> it keeps this state, even if it CLOSEd the filehandle and reOPENed it.
>> Otherwise, if it sends a LAYOUTGET using the new open_stateid, it will
>> implicitly return its previous layout state, as per our forgetful client
>> model and the semantics discussed for LAYOUTGET using non-layout stateid.
>
> Good catch.
>
> Is this going to be an issue for existing clients, who might not be expecting
> this to happen, given that RFC5661 didn't say this explicitly?
The errata might be clarifying RFC5661, based on the following text.
Existing clients should expect this behavior anyway, the gist of the errata
is about serializing the LAYOUTGETs wityh non-layout stateid, no their
expected semantics.
12.5.2. Getting a Layout
In order to get a layout, the client must first have opened the file
via the OPEN operation. When a client has no layout on a file, it
MUST present an open stateid, a delegation stateid, or a byte-range
lock stateid in the loga_stateid argument. A successful LAYOUTGET
result includes a layout stateid. The first successful LAYOUTGET
processed by the server using a non-layout stateid as an argument
MUST have the "seqid" field of the layout stateid in the response set
to one. Thereafter, the client MUST use a layout stateid (see
Section 12.5.3) on future invocations of LAYOUTGET on the file, and
the "seqid" MUST NOT be set to zero. Once the layout has been
retrieved, it can be held across multiple OPEN and CLOSE sequences.
Therefore, a client may hold a layout for a file that is not
currently open by any user on the client. This allows for the
caching of layouts beyond CLOSE.
_______________________________________________
nfsv4 mailing list
nfsv4@...
https://www.ietf.org/mailman/listinfo/nfsv4
« Return to Thread: layout return - final update ?
| Free embeddable forum powered by Nabble | Forum Help |
