Subject: [nfsv4] New LAYOUTCOMMIT errata text for 5661

From: <[email-masked]>
Date: Fri, 8 Jul 2011 20:39:22 -0400

A day late, but here's the revised errata text for this that includes everything Benny
found.  See attached file.

I've tried to deal with the variation of commit effect among layout types (file and
object commit the entire layout, block doesn't) by using a concept of the "scope" of
a LAYOUTCOMMIT operation to replace references to the byte range defined by the
to-be-deprecated loca_offset and loca_length arguments.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

---

From: "Mike Eisler" <[email-masked]>
Date: Sat, 9 Jul 2011 07:53:16 -0700

Apologies if there is a discussion I've missed, but:

   The
   client SHOULD set loca_offset to 0 and SHOULD set loca_length to the
   offset that the client expects for EOF after the LAYOUTCOMMIT.
   The server MUST ignore the loca_offset and loca_length arguments.

If the server MUST ignore loca_length, then why burden the client with a
mandate to determine the "offset that the client expects for EOF after the
LAYOUTCOMMIT."

And BTW, I'm not sure what "offset that the client expects for EOF after
the LAYOUTCOMMIT" is.

Regardless, I suggest,

   The
   client SHOULD set both loca_offset and loca_length to 0.

On Fri, July 8, 2011 5:39 pm, [email-masked] wrote:
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

-- 
Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
http://blogs.netapp.com/eislers_nfs_blog/

---

From: "Welch, Brent" <[email-masked]>
Date: Sat, 9 Jul 2011 17:53:33 +0000

Yeah, LAYOUTCOMMIT already takes loca_last_write_offset which is all the client knows.  loca_length should be 0.
	Brent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Eisler
Sent: Saturday, July 09, 2011 7:53 AM
To: [email-masked]
Subject: Re: [nfsv4] New LAYOUTCOMMIT errata text for 5661

   The

Regardless, I suggest,

   The

---

From: Benny Halevy <[email-masked]>
Date: Sun, 10 Jul 2011 14:12:38 +0300

> Yeah, LAYOUTCOMMIT already takes loca_last_write_offset which is all the client knows.  loca_length should be 0.

Agreed.

Benny

---

From: <[email-masked]>
Date: Sun, 10 Jul 2011 21:47:26 -0400

My rationale for the client to put EOF in loca_length was to get reasonable
behavior if a new client happens to talk to an old server that hasn't implemented
the "MUST ignore" requirement.

If loca_length is set to EOF (or some client view of what EOF is) by the client,
this new-client-old-server scenario only causes issues for the pNFS block layout.
If loca_length is set to 0 by the client, then this is also a concern for the
file and object layouts.

A subtlety here is that this is about errata for the existing NFSv4.1 RFC (5661).
I have no problem with NFS4.2 using "MUST" for everything (client MUST set both
values to 0, server MUST ignore them), based on the visible bump in the minor
version number.

How confident are people that the "MUST ignore" requirement for the byte range
will get into all the 4.1 servers so that this new-client-old-server scenario
can't happen?

Thanks,
--David

> From: Benny Halevy [mailto:[email-masked]]
> Sent: Sunday, July 10, 2011 7:13 AM
> To: Black, David
> Cc: Welch, Brent; Mike Eisler; [email-masked]

---

From: Benny Halevy <[email-masked]>
Date: Mon, 11 Jul 2011 08:57:42 +0300

> will get into all the 4.1 servers so that this new-client-old-server scenario

We either commit to this change or not.
A requirement for backward compatibility means server SHOULD ignore rather than
MUST ignore, which we don't want to do.

Since there are no commercial pnfs clients nor servers out in the market I'm
not worried about server vendors that do not follow the errata.
I expect all interested vendors to follow the spec + errata and the working
group discussion (as well as participate in the testing events, but this is
a separate issue).

Benny