Subject: [nfsv4] LAYOUTGET - requested versus returned range

From: "Mike Eisler" <[email-masked]>
Date: Thu, 1 May 2008 11:56:06 -0700 (PDT)

LAYOUTGET's definition in chapter 18 doesn't say anything whether
a server can return a layout that is excludes regions of the
requested range. Nor does it say if a server can return a layout that
includes more regions that requested.

Given the presence of loga_minlength, presumably the server can
return a layout that does excludes regions of the request range. E.g.
LAYOUTGET asks for 0, 1024, with minlength set to 512, and the
server returns 256,512.

Outside of chapter 12, we have:

   A client obtains a layout with the LAYOUTGET operation.  The metadata
   server will grant layouts of a particular type (e.g., block/volume,
   object, or file).  The client selects an appropriate layout type that
   the server supports and the client is prepared to use.  The layout
   returned to the client may not exactly align with the requested byte
   range.  A field within the LAYOUTGET request, loga_minlength,
   specifies the minimum length of the layout.  The loga_minlength field
   should be at least one.  As needed a client may make multiple
   LAYOUTGET requests; these will result in multiple overlapping, non-
   conflicting layouts.

What does "may not exactly align with the requested byte range" mean?
Why multiple overlapping layouts?

What should we say? And what does the client do if the server refuses to
give it the range it wants even after repeated LAYOUTGETs?

BTW ...

I hate loga_minlength
I hate loga_minlength
I hate loga_minlength
I hate loga_minlength
I hate loga_minlength
I hate loga_minlength
I hate loga_minlength

-- 
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: Robert Gordon <[email-masked]>
Date: Thu, 01 May 2008 19:33:23 -0500

> includes more regions that requested.

The only way to exclude a region would be to have additional elements
in the logr_layout array. Here in 18.43.3 we say

"The returned layout is expressed as an array, logr_layout, with each
element of type layout4. If a file has a single striping pattern, then
logr_layout will contain just one entry. Otherwise, if the requested
range overlaps more than one striping pattern, logr_layout will contain
the required number of entries. The elements of logr_layout MUST be  
sorted
in ascending order of the value of the lo_offset field of each element.
There MUST be no gaps or overlaps in the range between two successive
elements of logr_layout. The lo_iomode field in each element of
logr_layout MUST be the same."

So, one entry for a file with a single striping pattern. Further
if there is more than one pattern, no gaps ! :)

> LAYOUTGET asks for 0, 1024, with minlength set to 512, and the

Just to make sure i understand :-

  LAYOUTGET:
	loga_offset 	= 0;
	loga_length 	= 1024;
	loga_minlength	= 512;

to me this means the server must at a minimum provide a layout for
bytes 0 through 511 or return NFS4ERR_BADLAYOUT.

(looking still at chapter 12)

Robert..

---

From: Robert Gordon <[email-masked]>
Date: Thu, 01 May 2008 21:45:13 -0500

> What does "may not exactly align with the requested byte range" mean?

I've been assuming "may be larger than requested".

> Why multiple overlapping layouts?

And for this i had visualized :-
(let's assume that the loga_minlength really is applied to the offset)

i) LAYOUTGET:
	loga_offset 	= 0;
	loga_length 	= -1;
	loga_minlength	=  8k;

    LOGR:
	lo_offset	= 0;
	lo_length	= 8k;

ii) LAYOUTGET:
	loga_offset 	= 0;
	loga_length 	= -1;
	loga_minlength	=  16k;

    LOGR:
	lo_offset	= 0;
	lo_length	= 16k;

iii) LAYOUTGET:
	loga_offset 	= 0;
	loga_length 	= -1;
	loga_minlength	=  24k;

    LOGR:
	lo_offset	= 0;
	lo_length	= 24k;

> give it the range it wants even after repeated LAYOUTGETs?

So, I think i understand how a client might end up with a gap..

1) LAYOUTGET:
	loga_offset 	= 0;
	loga_length 	= -1;
	loga_minlength	=  8k;

    LOGR:
	lo_offset	= 0;
	lo_length	= 8k;

2) LAYOUTGET:
	loga_offset 	= 16k;
	loga_length 	= -1;
	loga_minlength	=  8k;

    LOGR:
	lo_offset	= 16k;
	lo_length	= 8k;

now the client has a gap in the byte range, and the server always  
replies
with TRYLATER when the client attempts to obtain a layout for the  
missing
byte range..

I think that client has the choice to return the entire file layout  
and perform
IO through the MDS,
   or
perform IO to the MDS for the byte ranges it does not hold a layout,  
and IO
to the data servers that it does hold a layout.

For a long while i had assumed that if the client did perform IO to
the MDS, that it would first return the entire file layout, or if I  
(the MDS)
detected IO i would recall the entire layout.. Being of the mind, all IO
through MDS or all IO to the data servers (not a mixture)

Robert..

---

From: "Mike Eisler" <[email-masked]>
Date: Fri, 2 May 2008 09:55:20 -0700 (PDT)

> I've been assuming "may be larger than requested".

Then why have loga_minlength?

> (let's assume that the loga_minlength really is applied to the offset)

But the spec doesn't say that.

> 	lo_length	= 8k;

These, and the rest of the examples are not "larger than requested".

> with TRYLATER when the client attempts to obtain a layout for the

The client has a gap, because it asked for a gap.

Why does TRYLATER result, always, when the client tries to fill the
gap?

> to the data servers that it does hold a layout.

Yes.

> through MDS or all IO to the data servers (not a mixture)

Since any client can write to the MDS, the client that holds a layout
can also write to the MDS.