Subject: Re: [nfsv4] wordsmithing for remainder of chapter 18

From: Benny Halevy <[email-masked]>
Date: Thu, 01 May 2008 13:05:33 +0300

On May. 01, 2008, 7:13 +0300, "Mike Eisler" <[email-masked]> wrote:
> http://eisler.com/nfsv4-wg/2008-04-30-ch-18-backchannel_ctl.html
> 
> http://eisler.com/nfsv4-wg/2008-04-30-ch-18-backchannel_ctl.txt
> 
> http://eisler.com/nfsv4-wg/2008-04-30-ch-18-backchannel_ctl_cvs_src.txt
> 
> 

Parse error :)
+            The server schedules the replacement of
+            both records are atomically replaced with:

---

-      conditions. Notifications would not be requested when the goal
+      conditions. Notifications should not be requested when the goal
       is just cache consistency.

How about removing the last sentence or replacing it with a
more substantial one?
As guidance to the client implementor or to the implementation
it's too vague and non-technical.  Why the "goal" has anything to do
with that?  The question in hand is what benefits dir delegations 
provide.  If the goal of the implementor was "just" to make his
cache consistency algorithms simpler but dir delegations do provide
performance benefits by improving network utilizations I think
the client should request them.  OTOH if they cause too much
callback traffic for some reason they shouldn't be requested.
How would the client know, dynamically, I'm not sure...

---

-      The client should use a security flavor that the file system is
-      exported with. If it uses a different flavor, the server should
+      The client should use a security tuple that the file system is

client SHOULD?

+      exported with. If it uses a different tuple, the server should
       return NFS4ERR_WRONGSEC
server SHOULD?

why not MUST by the way?
If the file system supports several security tuples it should list them,
no?

---

+      If loga_length is zero,...
+      the error NFS4ERR_INVAL will result.

[unrelated to the wordsmithing changes]
Is the really necessary?

The scenario I'm thinking of is an opportunistic LAYOUTGET
sent with an OPEN, before the client has any data to write (or read).

In this case if it sends a LAYOUTGET with loga_length > 0,
our server (as well as block-based servers I assume) will provisionally
allocate storage to back the layout range while, if no data currently
exist in the range, I would like to avoid the provisional allocation
by allowing the server to optionally return a layout if it has one.
Note that the server has no problem to return a layout for a longer
byte range than 0 bytes.

---

-      If the operation specified lr_returntype of LAYOUTRETURN4_FILE,
-      then lrs_stateid will represent the layout stateid as
+      If the operation set the lr_returntype field to LAYOUTRETURN4_FILE,
                        ^^^
                        sets
+      then the lrs_stateid field will represent the layout stateid as

---

-      operation must be done as a completing operation, lrs_present
-      MUST be FALSE, and thus no stateid will be returned.
+      operation must be done, lrs_present
+      MUST be FALSE, and thus no stateid will be returned and the current
+      stateid will be cleared.

[see my reply on a different thread]
To make that a bit clearer I suggest the following text:

-      operation must be done as a completing operation, lrs_present
-      MUST be FALSE, and thus no stateid will be returned.
+      operation must be done, lrs_present
+      MUST be FALSE, and thus no stateid will be returned and the current
+      stateid will be invalidated.
+      The server MUST reject any further use of the current
+      stateid in that COMPOUND with NFS4ERR_BAD_STATEID
+      until the current stateid is re-established by another
+      stateid-returning operation.

---

--- nfsv41_middle_op_want_delegation.xml	19 Mar 2008 05:04:46 -0000	1.16
+++ nfsv41_middle_op_want_delegation.xml	1 May 2008 04:07:18 -0000
@@ -17,30 +17,38 @@
       apply, the server MAY return any of the mandated error codes.
     </t>
     <t>
-      This operation allows a client to
+      The server MAY support this operation. If the
+      server does not support this operation, it MUST
+      return NFS4ERR_NOTSUPP.

Isn't that true for all optional operations?
Why mention it specifically here?

+

<nit>extra empty line...</nit>

+    </t>

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 1 May 2008 10:23:23 -0400

> http://eisler.com/nfsv4-wg/2008-04-30-ch-18-backchannel_ctl_cvs_src.txt

Three choices, yowza; thanks.

+      is described here.
+      <list style='symbols'>
+      <t>
+       The client reconnects.
+      </t>
+      <t>
+       The client assumes the SET_SSV was executed,
+       and so sends BIND_CONN_TO_SESSION with the subkey derived from
+       new SSV (what SET_SSV would have set the SSV to)

Should there be a "the" before "new SSV"?

+       used as the key for the RPCSEC_GSS credential message integrity
codes.
+      </t>
+      <t>
+       If the request succeeds, this means the original attempted
SET_SSV
+       did execute successfully. The client re-sends the original
+       SET_SSV, which the server will reply from via the

Maybe that should be "reply to via", or "reply to from"?

--b.

+       the reply cache.
+      </t>
+      <t>
+       If the server returns an RPC authentication error,
+       this means the server's current SSV was not changed,
+       (and the SET_SSV was likely not executed).  The client then
+       tries BIND_CONN_TO_SESSION with the subkey derived from the
+       old SSV as the
+       key for the RPCSEC_GSS message integrity codes.
+      </t>
+      <t>
+       The attempted BIND_CONN_TO_SESSION with the old SSV
+       should succeed. If so the client re-sends the original
+       SET_SSV. If the original SET_SSV was not executed, then the
+       server executes it. If the original SET_SSV was executed, but
+       failed, the server will return the SET_SSV from the reply
+       cache.
+      </t>
+
+     </list>

---

From: "Mike Eisler" <[email-masked]>
Date: Thu, 1 May 2008 07:24:29 -0700 (PDT)

> Note that the server has no problem to return a layout for a longer

case 1. If you have a zero length file, you will provisionally allocate
storage if the client asks for a layout larger than zero bytes.

case 2. If the client asks for a zero length layout,
your server will return a layout that is not zero length, and your
server will not provisionally allocate storage.

I think it is simpler if your servers not provisionally allocate any
storage in either case.

Regardless, I think making such a change, now, is not necessary.

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

---

From: Benny Halevy <[email-masked]>
Date: Thu, 01 May 2008 17:38:50 +0300

> storage if the client asks for a layout larger than zero bytes.

So how else would you extend the file (pnfs only, no write to MDS)
if not by asking for a write layout with non-zero length?

> server will not provisionally allocate storage.

right.

> I think it is simpler if your servers not provisionally allocate any

I'm not sure I understood your case 1 then.

> Regardless, I think making such a change, now, is not necessary.

Well, this pretty much rules out opportunistic LAYOUTGET on OPEN
for write with our back end.  We can live with that, but it complicates
the client since it makes this feature a layout driver policy.

What does it break to allow zero-length LAYOUTGET?

Benny

---

From: "Mike Eisler" <[email-masked]>
Date: Thu, 1 May 2008 07:50:08 -0700 (PDT)

>> server will not provisionally allocate storage.

And you don't see a contradiction?

If the server can avoid provisionally allocating storage for case 2, then
why can't it avoid provisionally allocating storage for case 1?

What layout range were you planning on returning for case 2?
Why can't you return the same layout range for case 1?

If you return a layout range for case 2, and the client tries to
use it (sends an OSD or SCSI Write command to the storage
device), what happens? Presumably allocation starts then.

> What does it break to allow zero-length LAYOUTGET?

What does it solve?

What do text do I put in specification when a zero-length layout request
is received?

---

From: Fredric Isaman <[email-masked]>
Date: Thu, 1 May 2008 10:52:01 -0400 (EDT)

> server will not provisionally allocate storage.

Note that the block layout pretty much has to provisionally allocate 
storage if it returns a non-zero length layout.

 	Fred

---

From: Benny Halevy <[email-masked]>
Date: Thu, 01 May 2008 18:11:18 +0300

> why can't it avoid provisionally allocating storage for case 1?

OK, I assumed that in case 2 you're talking about a non-empty file.

> What layout range were you planning on returning for case 2?

For an empty file, I would return no layout, just NFS4ERR_LAYOUTTRYLATER.

> Why can't you return the same layout range for case 1?

Since when the client asks for a write layout, I provisionally
allocate resources on storage for that range so it has space to write to.

> device), what happens? Presumably allocation starts then.

It is true that for objects block allocation may be deferred to
the actual write time, but the objects themselves have to be created
in advance.

> What do text do I put in specification when a zero-length layout request

Nothing special.
	The metadata server may adjust the range of the returned layout based
	on the usage implied by the loga_iomode.
already provides for returning a longer range than requested.

Benny

---

From: "Noveck, Dave" <[email-masked]>
Date: Thu, 1 May 2008 11:35:20 -0400

I'm confused by this.  Let's take away for a minute a discussion of
motivation and what particular servers might or might not do.  Let me
ask one question.  Is there agreement that servers cannot return a
layout of zero length.  I'm assuming that there would nothing that a
client could do with one, and given that it doesn't make any sense to
allow that.

If that is true, then what is the value of allowing zero-length layout
request, as opposed to a layout request for one byte.  In either case,
the only thing that the server can return is a layout of one or more
bytes.  Given that, what is the difference between requesting zero bytes
and requesting one byte?

What am I missing?

-----Original Message-----
From: Benny Halevy [mailto:[email-masked]] 
Sent: Thursday, May 01, 2008 11:11 AM
To: Mike Eisler
Cc: [email-masked]
Subject: Re: [nfsv4] zero length layouts

> What layout range were you planning on returning for case 2?

For an empty file, I would return no layout, just
NFS4ERR_LAYOUTTRYLATER.

Since when the client asks for a write layout, I provisionally
allocate resources on storage for that range so it has space to write
to.

> What do text do I put in specification when a zero-length layout
request

Nothing special.
	The metadata server may adjust the range of the returned layout
based
	on the usage implied by the loga_iomode.
already provides for returning a longer range than requested.

Benny

---

From: Robert Gordon <[email-masked]>
Date: Thu, 01 May 2008 10:44:06 -0500

I was thinking that a zero length LAYOUTGET meant the
following (pardon my very non-spec speak) :-

" Hey server if you already have a layout for this file,
give it to me, if not then don't go to the trouble of
creating one, i'll ask for it once i know the exact
range that i need"

Robert.

---

From: Benny Halevy <[email-masked]>
Date: Thu, 01 May 2008 19:56:33 +0300

right.

>> client could do with one, and given that it doesn't make any sense to

No, I don't think that in the pnfs world (where the client is interested
only in *data* stored on data servers) there is a need to support that.

>> bytes.  Given that, what is the difference between requesting zero  

Requesting a (write) layout for zero bytes makes an optional request that
the server can gracefully decline if there is no layout in that range.
Otherwise, the server needs to create the layout for that byte range
and provisionally allocate resources on the storage devices to back it.

Benny

---

From: [email-masked]
Date: Thu, 1 May 2008 14:23:35 -0400

I think this is a useful optimization that can be used as Benny
describes for block based layouts as well.  It seems logical to me to
allow for such flexibility in the protocol.

-Jason
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Benny Halevy
> Sent: Thursday, May 01, 2008 12:57 PM
> To: Robert Gordon; Noveck, Dave
> Cc: [email-masked]

---

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

>> creating one, i'll ask for it once i know the exact

And what if the layout the server happens to have (btw, I think
you both really mean, that the server has already assigning a striping
pattern, not necessarily previously given out a layout) is of no
use to the client? Now we've assigned a recallable object that
the client cannot use.

I think more information needs to be conveyed in LAYOUTGET to
accomplish what Robert, Benny, and Jason want, which probably means
a .x change. E.g. a flag that says, if set, "give me a layout for the
specified range if it doesn't entail provisioning storage."

> the server can gracefully decline if there is no layout in that range.

What range? The length is zero, there is no range.

> and provisionally allocate resources on the storage devices to back it.

So rather than overloading a zero length, what is being requested
is a brand new feature. Considering where we are in the process,
the WG needs to consider the request on that merit.

---

From: Robert Gordon <[email-masked]>
Date: Thu, 01 May 2008 17:44:56 -0500

On May 1, 2008, at 1:40 PM, Mike Eisler wrote:

> And what if the layout the server happens to have

> (btw, I think
> pattern, not necessarily previously given out a layout)

Yes.

> is of no use to the client? Now we've assigned a recallable object  
> that
> the client cannot use.

My general assumption has been (for files) for the common usage
that the server will return a layout for the entire file.

> specified range if it doesn't entail provisioning storage."

I think we would all agree, however as you have noted below it is
late in the process...  :)

> the WG needs to consider the request on that merit.

One could be creative and assume that an OPEN followed by
a LAYOUTGET (using the current stateid) is speculative, and if
resources have already been assigned return the layout the client
asked for.. If not then of course return NFS4ERR_LAYOUTTRYLATER;
only on the subsequent LAYOUTGET would the server go to the 'trouble'
of allocation resources etc...

This would mean no dot-x changes, keep the INVAL error for zero
loga_length, and maybe most people would be happy..

Robert..

---

From: Benny Halevy <[email-masked]>
Date: Fri, 02 May 2008 12:33:59 +0300

> late in the process...  :)

Adding a flag could have been a semantically cleaner solution but I
agree it is indeed too late for that.  However, I assume the client still
has no data to write at this point so passing zero length for the
layoutget conveys the actual state the client is in. Therefore it makes
sense to overload that for the purpose we discuss.

>> What range? The length is zero, there is no range.

yeah, yeah, a zero bytes long range is not really a range.
The range I was talking about just covers the byte at the starting offset.

>> the WG needs to consider the request on that merit.

I didn't ask for a .x change.  What I'm asking for pretty much falls
on these lines:

diff -Nurp -u /home/bhalevy/pnfs/draft-ietf-nfsv4-minorversion1-22.txt /tmp/draft-ietf-nfsv4-minorversion1-22-bh.txt
--- /home/bhalevy/pnfs/draft-ietf-nfsv4-minorversion1-22.txt	2008-05-02 09:34:40.000000000 +0300
+++ /tmp/draft-ietf-nfsv4-minorversion1-22-bh.txt	2008-05-02 12:27:43.000000000 +0300
@@ -29223,6 +29223,17 @@ Internet-Draft                   NFSv4.1
    layouts and device ID to device address mappings, then it MUST return
    NFS4ERR_GRACE (see Section 8.4.2.1).
 
+   The loga_offset and loga_length fields specify together the byte-
+   range for which the layout is requested, with one exception: if
+   loga_length is set to zero, the requested byte range is considered
+   to be one byte long.  The client uses this special value to indicate
+   an opportunistic LAYOUTGET, typically sent before the client has any
+   data to read from or write to this range, but it would like to
+   prefetch the layout in anticipation to future I/O.  If the server
+   has not already provisioned storage holding the byte at loga_offset
+   and loga_length is set to zero then the server SHOULD return
+   NFS4ERR_LAYOUTTRYLATER.
+
    The LAYOUTGET operation returns layout information for the specified
    byte range: a layout.  To get a layout from a specific offset through
 
@@ -29234,18 +29245,22 @@ Internet-Draft                   NFSv4.1

    the end-of-file, regardless of the file's length, a loga_length field
-   set to NFS4_UINT64_MAX is used.  If loga_length is zero, or if a
-   loga_length which is not NFS4_UINT64_MAX is specified, and the sum of
+   set to NFS4_UINT64_MAX is used.  If a
+   loga_length which is not NFS4_UINT64_MAX is specified and the sum of
    loga_length and loga_offset exceeds NFS4_UINT64_MAX, the error
    NFS4ERR_INVAL will result.
 
    The loga_minlength field specifies the minimum length of layout the
-   server MUST return with two exceptions:
+   server MUST return with three exceptions:
 
    1.  The argument loga_iomode was set to LAYOUTIOMODE_READ, and
        loga_offset plus loga_minlength goes past the end of the file.
 
-   2.  The range from loga_offset through loga_offset + loga_minlength -
+   2.  The argument loga_iomode was set to LAYOUTIOMODE_WRITE,
+       loga_length was set to zero, and loga_offset plus loga_minlength goes
+       past the end of the file.
+
+   3.  The range from loga_offset through loga_offset + loga_minlength -
        1 overlaps two or more striping patterns.  In which case,
        logr_layout will contain two or more elements, and the sum of the
        lo_length fields of each element MUST be at least loga_minlength

> of allocation resources etc...

I don't like that too much as the client may want to prefetch the
layout at a later time and for different offsets.

> loga_length, and maybe most people would be happy..

Real "design by committee" panacea ;-)

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.
The 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: Fri, 2 May 2008 06:57:52 -0700 (PDT)

http://linux-nfs.org/pipermail/nfsv4/2008-January/007453.html

As you can see from the above link and in

   http://linux-nfs.org/pipermail/nfsv4/2008-January/thread.html

the Linux community is really annoyed with pNFS. I understand at the
LSF '08/FDAST '08 even more derision was sent our way.

You guys really want Spencer or Dave (it SAF won't be me) to put
the following idea in the spec?

On Fri, May 2, 2008 2:33 am, Benny Halevy wrote:
> diff -Nurp -u /home/bhalevy/pnfs/draft-ietf-nfsv4-minorversion1-22.txt
> /tmp/draft-ietf-nfsv4-minorversion1-22-bh.txt

---

From: Robert Gordon <[email-masked]>
Date: Fri, 02 May 2008 09:36:57 -0500

> the following idea in the spec?

No, add the flag, change the dot-x.. move on :)

Robert.

---

From: Benny Halevy <[email-masked]>
Date: Fri, 02 May 2008 18:45:59 +0300

> the following idea in the spec?

Well, if they are going to be flamed about it, why not? :)
Seriously, you're suggesting a weird way of affecting this working group's
decision making process.  I'm sure that anything you'll do you'd find 
somebody
(or even two) that won't agree with your taste.  However, I care more about
having the best possible protocol we can make within realistic time and
resources constraints.  In this particular case, I think the ROI on the 
proposed
semantic hack is high enough to be considered to let into the spec as the
premise is potential performance enhancement via layout prefetching
with no .x change and relatively minor semantic change.

Benny

---

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

> decision making process.  I'm sure that anything you'll do you'd find

IETF's credo is rough consensus and running code.

The practical corrollary to "running code" is that if both
Bill or Linus won't support it, no one cares. This, for example,
was the reason why we essentially ripped out i18n support, because
Bill ain't doing NFSv4, and Linus ain't doing UTF-8.

> with no .x change and relatively minor semantic change.

If you guys thought the ROI was there, why are you mentioning it now?
Surely you've implemented prototypes of LAYOUTGET by now.

I think if there is rough consensus to do this (and I'd have to hear
from more than 3 people to discern a rough consensus on this type of
change at this point in the process), we do this in a cleaner way.

Or you bribe Spencer or Dave to write the hack text.

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 02 May 2008 11:49:47 -0500

> change at this point in the process), we do this in a cleaner way.

Yes, there needs to be a clearer sign of support for the change;
Consider this a query for that support.

I also agree that if this is to be done, do it cleanly.

Spencer

---

From: Dean Hildebrand <[email-masked]>
Date: Fri, 02 May 2008 11:38:58 -0700

> I also agree that if this is to be done, do it cleanly.
I can see why we would want the flag as we had talked about bundling 
LAYOUTGET with OPEN back in 2005.  It seems though that our wishes were 
not expressed early enough to the NFSv4 list....

I would also like the flag, but it is far from critical.  Each file 
system can interpret the arguments of the LAYOUTGET request however it 
wishes.  As Robert said earlier, if a client wants to send a 1 byte 
LAYOUTGET request (instead of a 0 request), the file system has the 
option of doing whatever it wishes, e.g., allocate space, not allocate 
space, return a whole file layout, return NFS4ERR_LAYOUTTRYLATER, return 
a layout for 1 byte, return a layout for 1 block....  As a file system 
implementor, the expressed wishes of the client are less important than 
what the file system believes is best.  In addition, the optimization is 
only good if clients utilize it, and it is not clear that 
sun/linux/aix/xxx will all use any flag that is put into the protocol.

My guess would be that if we don't get the flag, the linux client will, 
if a layout driver wishes, request a layoutget in the same compound as 
an open for a single page/block/byte/something....

Dean

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 02 May 2008 13:43:46 -0500

On May 2, 2008, at 1:38 PM, Dean Hildebrand wrote:
> I can see why we would want the flag as we had talked about  
> bundling LAYOUTGET with OPEN back in 2005.  It seems though that  
> our wishes were not expressed early enough to the NFSv4 list....
>
> system can interpret the arguments of the LAYOUTGET request however  
> it wishes.  As Robert said earlier, if a client wants to send a 1  
> byte LAYOUTGET request (instead of a 0 request), the file system  
> has the option of doing whatever it wishes, e.g., allocate space,  
> not allocate space, return a whole file layout, return  
> NFS4ERR_LAYOUTTRYLATER, return a layout for 1 byte, return a layout  
> for 1 block....  As a file system implementor, the expressed wishes  
> of the client are less important than what the file system believes  
> is best.  In addition, the optimization is only good if clients  
> utilize it, and it is not clear that sun/linux/aix/xxx will all use  
> any flag that is put into the protocol.
>
> My guess would be that if we don't get the flag, the linux client  
> will, if a layout driver wishes, request a layoutget in the same  
> compound as an open for a single page/block/byte/something....

Are you suggesting that this will be done as a defacto method
the zero length return?
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Dean Hildebrand <[email-masked]>
Date: Fri, 02 May 2008 11:46:55 -0700

Spencer Shepler wrote:
>> LAYOUTGET with OPEN back in 2005.  It seems though that our wishes 
>> were not expressed early enough to the NFSv4 list....
>>
>> byte LAYOUTGET request (instead of a 0 request), the file system has 
>> the option of doing whatever it wishes, e.g., allocate space, not 
>> allocate space, return a whole file layout, return 
Sorry, not sure what you mean, could you elaborate/restate?
Dean
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Fri, 02 May 2008 13:51:12 -0500

On May 2, 2008, at 1:46 PM, Dean Hildebrand wrote:

>>> I would also like the flag, but it is far from critical.  Each  
>>> file system can interpret the arguments of the LAYOUTGET request  
>>> however it wishes.  As Robert said earlier, if a client wants to  
>>> send a 1 byte LAYOUTGET request (instead of a 0 request), the  
>>> file system has the option of doing whatever it wishes, e.g.,  
>>> allocate space, not allocate space, return a whole file layout,  
>>> return NFS4ERR_LAYOUTTRYLATER, return a layout for 1 byte, return  
>>> a layout for 1 block....  As a file system implementor, the  
>>> expressed wishes of the client are less important than what the  
>>> file system believes is best.  In addition, the optimization is  
>>> only good if clients utilize it, and it is not clear that sun/ 
>>> linux/aix/xxx will all use any flag that is put into the protocol.
>>>

It appears that you are asserting that if the protocol
does not include a flag to do the "zero length layout" thing
that the Linux client will adopt a known behavior to
communicate the same thing and resulting in the desired
behavior.

If that is what you intended, then I would consider
that a strong statement of support for making a
protocol change.

Spencer

---

From: Dean Hildebrand <[email-masked]>
Date: Fri, 02 May 2008 12:04:19 -0700

> that a strong statement of support for making a
Ah, thanks for restating.  I guess you are right, although I wish that 
didn't mean a protocol change.
My one qualification is that from a file layout point of view, this 
optimization is only for small files (or a small amount of I/O to large 
files).  For large I/O, the data transfer time dwarfs any extra round 
trips to the MDS for layoutget.  So for the scenario
OPEN
- small amount of I/O
CLOSE
requesting a layout for a single block/page at OPEN time might not be 
all that far off from the truth....
Dean

---

From: "Noveck, Dave" <[email-masked]>
Date: Sat, 3 May 2008 10:03:41 -0400

My interpretation was different and I really want us to think very
carefully befre considering making a .x change after group last call.  I
don't think that the client should really have a concept of "desired
behavior" in this sense.  It is up to the server to choose whether
layouts are granted, and the client communicates, as best he can, what
he will be doing in terms of IO by requesting layouts.

I thought it has always been understood that some files would be too
small to bother with for pnfs and the server would essentially tell the
client for these to do IO through the MDS.  I expected that each server
implementation would, after careful consideration of the appropriate
tradeoffs, extensive analytical work, intensive simulations and
empirical validation (or by picking a number out of air :-), establish
some value X such that files below that size are dealt with through the
MDS, via NFS as it has always existed (more or less).  If the file is
smaller than that and the layout request wouldn't make it any bigger
than that, then sorry no layout.

I can see how a server might choose to have a different value Y if
certain work as already been done, and even that that value might be as
low as 1 byte.  The result of this might be that even if a client
requested a layout as small as one byte, the server might choose to
grant it, but the one byte would indicate what the client thought he
would write, and not how he thinks the server should choose to grant or
not grant layouts.  That's not really his business.

I would expect that the client would also have his own conception of
when it was worth doing something other than IO through the MDS so, in
practical terms, I would not expect him to bother to request layouts
that were so small.  For this reason, I would imagine that layouts would
typically not be requested by clients at OPEN time.  Certainly, if I was
writing a client, I would wait until I saw the application doing a
megabyte write or we were flushing a lot of smaller writes.  The client
always has to be prepared for the case of layouts not being available
and given that I would expect he would avoid asking for them until he
had a good reason to do so.  Client-writers can jump in here and explain
what I'm missing.

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]] 
Sent: Friday, May 02, 2008 2:51 PM
To: Dean Hildebrand
Cc: NFSv4
Subject: Re: [nfsv4] zero length layouts

>>> utilize it, and it is not clear that sun/ linux/aix/xxx will all use

>> Are you suggesting that this will be done as a defacto method the 
>> zero length return?

It appears that you are asserting that if the protocol does not include
a flag to do the "zero length layout" thing that the Linux client will
adopt a known behavior to communicate the same thing and resulting in
the desired behavior.

If that is what you intended, then I would consider that a strong
statement of support for making a protocol change.

Spencer

---

From: "Mike Eisler" <[email-masked]>
Date: Sat, 3 May 2008 07:15:07 -0700 (PDT)

> carefully befre considering making a .x change after group last call.  I

In another thread, which has loga_length and loga_minlength in the title,
I've explained how, by actually defining (I won't use re-define, since
that would be an insult to people who write dictionaries) what loga_length
and loga_minlenth mean, we could allow loga_minlength to be zero and have
it
mean what proponents for sloppy LAYOUTGETs want without a .x change.

In the interest of expediency I suggest people consider that proposal.

None of this detracts from your points about it often being insane to request
a layout when one has no inkling about how the file is going to be used,
and I  will plan on adding text to the IMPLEMENTATION section of LAYOUTGET
that
goes over your points.