Subject: [nfsv4] layoutget and other wordsmithing changes

From: "Mike Eisler" <[email-masked]>
Date: Wed, 7 May 2008 10:03:31 -0700 (PDT)

http://eisler.com/2008-05-07/

These represent the changes to support loga_minlen == 0,
added examples of LAYOUTGET, and errors reported by Jason Glasgow and Robert
Gordon. The changes are relative to draft-22, so many of the changes are
not new to readers.

This might be the draft we give to the Area Advisor.

I will be at Connectathon on Monday.

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

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: [email-masked]
Date: Wed, 7 May 2008 13:25:15 -0400

Mike,

I like the wording and explanations.

Two nits.

s/lofa_offset/loga_offset/

s/thney/they/

-Jason

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Mike Eisler
> Sent: Wednesday, May 07, 2008 1:04 PM
> To: [email-masked]
> Subject: [nfsv4] layoutget and other wordsmithing changes
>

---

From: "Mike Eisler" <[email-masked]>
Date: Wed, 7 May 2008 11:35:00 -0700 (PDT)

Thx.

Updated i-d and pushed to:
   http://eisler.com/2008-05-07/

I will do a final spell check after I checkin ... my cygwin
environment doesn't have real UNIX spell.

---

From: Benny Halevy <[email-masked]>
Date: Wed, 07 May 2008 12:27:07 -0700

Mike, thanks for your patience!
I agree with the text in this proposal
and like most of it.

since 
I think you have a mistake in this example:
+   o  A process on the client invokes a request to read from offset
+      10000 for length 50000.  The client is using buffered I/O, and has
+      buffer sizes of 4096 bytes.  The client intends to map the request
+      of the process into a series of READ requests starting at offset
+      8192, with a total length of 61440 (which equals 15 * 4096).  The

s/61440/53248/ as 61440 is the end offset of the last page in the range
(8192 + 53248 = 61440)

s/15/13/ similarly

+      value of threshold4_read_iosize is less than 61440, so the client
+      sends a LAYOUTGET request with loga_offset set to 8192,
+      loga_minlength set to 61440, and loga_length set to the file's

s/61440/53248/

+      length (if known) minus 8192 or NFS4_UINT64_MAX (if the file's
+      length is not known).  Since this LAYOUTGET request exceeds the
+      metadata server's threshold, it grants the layout, possibly with
+      an initial offset of 0, with an end offset of at least 8192 +
+      61440 - 1 = 69631, but preferably a layout with an offset aligned

8192 + 53248 - 1 = 61439
+      on the stripe width and a length that is a multiple of the stripe
+      width.

Now this example and the next one both encourage the client to send loga_minlength
representing the *complete* range the client wants to read from or
write to.

While that works well for servers who can always return the full layout,
it is problematic for our server as well as block-based servers which might have a
problem to satisfy requests with large loga_minlength within loga_maxcount.

In order to prevent such errors, rather than having to apply error handling for them
I propose to add the following example right after the one mentioned above:

+   o  As above, but the client is expecting that the server may not be
+      able to return the layout for the full I/O range, with loga_offset
+      set to 8192 and loga_minlength set to 53248.
+      The client intends to map the request of the process into a series of
+      READ requests starting at offset 8192, with a total length of 53248
+      (which equals 13 * 4096) and it may use several LAYOUTGETs to complete
+      the series of READs.
+      The client sends a LAYOUTGET request with loga_offset set to 8192,
+      loga_minlength set to 4096, and loga_length set to 53248 or higher.
+      The server will grant a layout possibly with an initial offset of 0,
+      with an end offset of at least 8192 + 4096 - 1 = 12287,
+      but preferably a layout with an offset aligned
+      on the stripe width and a length that is a multiple of the stripe
+      width.  This will allow the client to make forward progress, possibly
+      having to issue more LAYOUTGET requests for the remainder of the range.

And a few more nits:
+   o  If loga_length is less than loga_minlength, the metadata server
+      MUST return NFS4ERR_INAL.
	NFS4ERR_INAL => NFS4ERR_INVAL

+      layout that fully overlaps the requested range, with a stsarting
	stsarting => starting

+      thney is protected with a security flavor that has integrity
	they

Thanks,

Benny

-- 
Benny Halevy
Software Architect
Tel/Fax: +972-3-647-8340
Mobile: +972-54-802-8340
US:      +1-412-203-3187
[email-masked]
 
Panasas, Inc.
Leader in Parallel Storage
www.panasas.com
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Mike Eisler <[email-masked]>
Date: Wed, 7 May 2008 17:12:53 -0700 (PDT)

(using Yahoo again, as eisler.com's ISP seems to being road work; what
do you expect for $5 a month?)

Great comments and example.

I've incorporated the example (with some re-wording), and
made the corrections below.

BTW, I also added the nfs41acl definition per Bruce's request.

I've pushed the changes, and again they are at:

--- Benny Halevy <[email-masked]> wrote:

> >> added examples of LAYOUTGET, and errors reported by Jason Glasgow
> and
> >> Robert
> >> Gordon. The changes are relative to draft-22, so many of the
> changes
> > are
> >> not new to readers.
> >>

---

From: Benny Halevy <[email-masked]>
Date: Wed, 07 May 2008 18:19:13 -0700

> http://eisler.com/2008-05-07/

Thanks Mike!

For some reason I don't see the most recent changes there though...
http://eisler.com/2008-05-07/ shows all files dated 07-May-2008 11:33

Benny

---

From: "Mike Eisler" <[email-masked]>
Date: Wed, 7 May 2008 23:19:27 -0700 (PDT)

I am sorry about that.

Please try again:

---

From: Robert Gordon <[email-masked]>
Date: Thu, 08 May 2008 01:33:53 -0700

>   http://eisler.com/2008-05-07/

minor nit:

was:

The logr_stateid stateid is returned to the client for use in	
subsequent layout related operations. See Section 8.2, Section 12.5.3,
and Section 12.5.5.2 for a further discussion and requirements.

Suggestion:

logr_stateid is returned to the client for use in	
subsequent layout related operations. See Section 8.2, Section 12.5.3,
and Section 12.5.5.2 for a further discussion and requirements.

--
Robert.

---

From: Robert Gordon <[email-masked]>
Date: Thu, 08 May 2008 02:07:34 -0700

>   http://eisler.com/2008-05-07/

I really like the juicy "18.43.4. IMPLEMENTATION" section..

:-D

Robert..