Subject: Re: [nfsv4] LAYOUTCOMMIT byte range

From: Thomas Haynes <[email-masked]>
Date: Tue, 3 May 2011 14:48:09 -0500

Is the intent here to provide a new errata for 5661?

If so, who is going to provide the text?

PS: I think we want to first get the text approved on the WG list
before the errata is filed.

On Apr 19, 2011, at 11:11 AM, <[email-masked]> <[email-masked]> wrote:

> Based on this message, it looks like the right way forward is to deprecate loca_offset and loca_length in the LAYOUTCOMMIT arguments, because:
> 
> - loca_last_write_offset will remain to handle EOF update.
> - The file and object layouts commit the entire file or object.
> - The block layout passes the ranges to commit in its layout-dependent arguments.
> 
> Thanks,
> --David
> 
>> -----Original Message-----
>> From: Benny Halevy [mailto:[email-masked]]
>> Sent: Monday, April 04, 2011 12:36 PM
>> To: Black, David
>> Cc: [email-masked]; [email-masked]; [email-masked]
>> Subject: Re: [nfsv4] LAYOUTCOMMIT byte range
>> 
>> On 2011-04-04 08:41, [email-masked] wrote:
>>>>> Also note that Benny is talking about deprecating loca_offset and
>>>>> loca_length, the thing you seem to care about is
>>>>> loca_last_write_offset, which is not affected
>>>> 
>>>> Sounds okay but would like to understand the details prior to
>>>> commenting on this part.
>>>> 
>>>> Questions: Will the client send LAYOUTCOMMIT to servers supporting
>>>> file layout in the current errata?
>>> 
>>> Yes - There should be no change to the carefully worked out
>>> requirements in the current errata for when LAYOUTCOMMIT has to be
>>> used with the pNFS file layout.
>>> 
>>>> I think if we deprecate loca_offset and loca_length the checks for,
>>>> loca_last_write_offset MUST overlap the range described by
>>>> loca_offset and loca_length need to be removed. There is more text
>>>> in rfc 5661 pertaining to mentioned fields up for deprecation.
>>> 
>>> Yes, it would be necessary to remove/rewrite all text referring to
>>> deprecated fields as part of deprecating them.  Removing those checks
>>> is one of the things I like about Benny's suggestion.
>>> 
>> 
>> In addition, since loca_last_write_offset is currently optional we may
>> want to mandate it when client wrote to the file via pNFS and did not
>> get FILE_SYNC (with the file layout).
>> 
>> loca_offset, loca_length were never meant to be used for determining
>> the file length.
>> 
>>> The overall result would be that for the pNFS block layout, the
>>> server iterates through the layout-specific extents to figure out
>>> what to do, but both the pNFS file and object layouts effectively do
>>> LAYOUTCOMMIT on the entire file.
>> 
>> Agreed,
>> 
>> Benny
>> 
>>> 
>>> Thanks, --David
>>> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: <[email-masked]>
Date: Tue, 3 May 2011 15:57:57 -0400

Tom,

I don't think this is an errata - I think it's a 4.2 change,
because a modified client that depends on the server ignoring 
the layout-independent byte range is going to be surprised
by an unmodified server that refuses to be ignorant ;-).
In other words, it's not backwards compatible wrt RFC 5661,
and there are server implementations that conform to RFC 5661
behavior.

I would suggest that a modified version of the LAYOUTCOMMIT
text from RFC 5661 should go into your 4.2 draft, with Benny
and yours truly being responsible for doing the necessary edits.
I don't think we need to change the dot-x file - leave the
arguments in, but the new text specifies that they're always
ignored.

Thanks,
--David

> From: Thomas Haynes [mailto:[email-masked]]
> Sent: Tuesday, May 03, 2011 3:48 PM
> To: Black, David
> Cc: [email-masked]; [email-masked]
> > Based on this message, it looks like the right way forward is to deprecate loca_offset and
> loca_length in the LAYOUTCOMMIT arguments, because:
> >

---

From: Thomas Haynes <[email-masked]>
Date: Tue, 3 May 2011 15:10:28 -0500

David,

In that case I'd like to add this as an agenda item for
the next meeting.

If all we do is discuss your plan below, then at least
we are all on the same page.

Thanks,
Tom

---

From: Thomas Haynes <[email-masked]>
Date: Tue, 3 May 2011 21:56:12 -0500

> arguments in, but the new text specifies that they're always

According to the minor versioning rules, we cannot remove the
arguments.

So if the minorversion field is 1, then the server must conform
to NFSv4.1 semantics. If the minorversion is 2, then the server
MUST conform to NFSv4.2 semantics.

This will not be optional, unlike when we add a new feature.

---

From: <[email-masked]>
Date: Wed, 4 May 2011 09:01:55 -0400

> According to the minor versioning rules, we cannot remove the

Nobody's proposing to remove the layout-independent byte range arguments;
the revised text would say that the arguments are present in the operation
and are (MUST be) ignored by the server.

> This will not be optional, unlike when we add a new feature.

That's what is needed, IMHO - an old client works with both old and new
servers, whereas a new client has to look for minorversion 2 before it
puts junk values into those arguments (minorversion 2 is the server's
promise to ignore those junk values).

Thanks,
--David

> Sent: Tuesday, May 03, 2011 10:56 PM
> To: Black, David

---

From: Thomas Haynes <[email-masked]>
Date: Wed, 4 May 2011 12:00:39 -0500

> and are (MUST be) ignored by the server.

Too terse, I wasn't suggesting you were proposing doing so, just pointing
out why you correctly stated the path to take.

---

From: Benny Halevy <[email-masked]>
Date: Mon, 09 May 2011 14:45:46 +0300

> and there are server implementations that conform to RFC 5661

That's what the errata is for, no?
Since the proposed changes simplify both the RFC, the client
and the server implementations and do not add any implementation
overhead I am inclined to have them as errata to RFC5661
applying to 4.2 as well.

> and yours truly being responsible for doing the necessary edits.

OK

> arguments in, but the new text specifies that they're always

Agreed.

Benny

---

From: <[email-masked]>
Date: Thu, 19 May 2011 17:49:38 -0400

I'm confused by this issue.  Maybe I just don't understand what is meant by "deprecating".

It seems that David Black is anticipating something like "the server MUST NOT look at these fields and the client MAY put any trash he wants and be sure it won't hurt.

How about something more like the following:

Having these filled in there (as indicated in RFC5661) was ill-advised, serving no useful purpose (that's my idea of deprecation, or at least it is the post-editorial-review version).

Unless the specific layout type specifies otherwise, all LAYOUTCOMMIT server implementations SHOULD ignore these fields an always commit the entire file/object.

In order to accommodate all servers, clients should set offset and length to cover the whole object so that severs that do not obey the "SHOULD" above, will not cause unpleasant surprises.

If that is the sort o errata we're talking bout, I agree that this would be a good thing to do.

---

If you have to deal with a server that 'refuses to stay ignorant', you can say nasty things about the implementer but be very careful when travelling through the UK :-)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Benny Halevy
Sent: Monday, May 09, 2011 7:46 AM
To: Black, David
Cc: [email-masked]
Subject: Re: [nfsv4] LAYOUTCOMMIT byte range

OK

Agreed.

Benny

---

From: <[email-masked]>
Date: Thu, 19 May 2011 20:16:53 -0400

Dave,

> Unless the specific layout type specifies otherwise, all LAYOUTCOMMIT server implementations SHOULD
> ignore these fields an always commit the entire file/object.
> 
> In order to accommodate all servers, clients should set offset and length to cover the whole object so
> that severs that do not obey the "SHOULD" above, will not cause unpleasant surprises.

I think that works as an errata with one change: "clients should set offset and length" -> "clients SHOULD set offset and length", but pNFS block implementers should double check that this client behavior won't cause them any problems.

I would still put a requirement that servers MUST ignore these fields into 4.2.

Thanks,
--David

> From: Noveck, David
> Sent: Thursday, May 19, 2011 5:50 PM
> To: Benny Halevy; Black, David
> Cc: [email-masked]
> Subject: RE: [nfsv4] LAYOUTCOMMIT byte range
> 
> It seems that David Black is anticipating something like "the server MUST NOT look at these fields and
> the client MAY put any trash he wants and be sure it won't hurt.
> 
> Having these filled in there (as indicated in RFC5661) was ill-advised, serving no useful purpose
> (that's my idea of deprecation, or at least it is the post-editorial-review version).
> 
> Unless the specific layout type specifies otherwise, all LAYOUTCOMMIT server implementations SHOULD
> ignore these fields an always commit the entire file/object.
> 
> In order to accommodate all servers, clients should set offset and length to cover the whole object so
> that severs that do not obey the "SHOULD" above, will not cause unpleasant surprises.
> 
> If you have to deal with a server that 'refuses to stay ignorant', you can say nasty things about the
> implementer but be very careful when travelling through the UK :-)
> 
> 
>

---

From: Benny Halevy <[email-masked]>
Date: Sun, 22 May 2011 20:15:45 +0300

> I would still put a requirement that servers MUST ignore these fields into 4.2.

Agreed to both comments.

Benny