Subject: Re: [nfsv4] wordsmithing for chapters 19-20

From: Benny Halevy <[email-masked]>
Date: Mon, 05 May 2008 16:44:07 +0300

Sorry for the late reply as I had a problem with my email.

Benny

On Sun, 4 May 2008 18:53:23 -0700 (PDT), Mike Eisler wrote:
> I have updated this to account for the comments on the
> loga_length/loga_minlength proposal, and the comments Robert Gordon
> had on other parts.

minor nit:
+       If loga_length is less than loga_minlength, the metadata server
+       MUST return NFS4ERR_INAL.
                    ^^^^^^^^^^^^
                    NFS4ERR_INVAL

---

+       If loga_length or loga_minlength are zero the metadata server
+       MUST return NFS4ERR_INVAL.

Can we discuss that during the connectathon?

I heard another interesting idea to redefine loga_signal_layout_avail,
say from bool to an enum or a u32 bitmap (not bitmap4)
(this was said on a private email, so if the person who said that
would like to identify himself: feel free to... :)

So that it can mean "THIS IS AN OPPORTUNISTIC LAYOUTGET".
This way loga_minlength can still be defined the same as regular LAYOUTGETs.
The dot-x definition will change but the on-the-wire format won't
really change.

---

+    Acceptable layouts based on loga_minlength (u64m = NFS4_UINT64_MAX)
+
+   +-----------+-----------+---------+-------------+-------------------+
+   | Request's | Request's | Reply's | Reply's     | Reply's layout    |
+   | layout    | layout    | layout  | layout      | length            |
+   | iomode    | minlength | iomode  | offset      |                   |
+   +-----------+-----------+---------+-------------+-------------------+
+   | _READ     | u64m      | MAY be  | MUST be <=  | MUST be >= file   |
+   |           |           | _READ   | loga_offset | length - layout   |
+   |           |           |         |             | offset            |
+   | _READ     | u64m      | MAY be  | MUST be <=  | MUST be u64m      |
+   |           |           | _WRITE  | loga_offset |                   |

1) _WRITE should be _RW, as in LAYOUTIOMODE4_RW,
2) Why the requirement for _RW?
   Why not to the current EOF as in the READ case?

+   | _READ     | < u64m    | MAY be  | MUST be <=  | MUST be >=        |
+   |           |           | _READ   | loga_offset | MIN(file length,  |
+   |           |           |         |             | loga_minlength +  |
+   |           |           |         |             | loga_offset) -    |
+   |           |           |         |             | layout offset     |
+   | _READ     | < u64m    | MAY be  | MUST be <=  | MUST be >=        |
+   |           |           | _WRITE  | loga_offset | loga_offset -     |
+   |           |           |         |             | layout offset +   |
+   |           |           |         |             | loga_minlength    |
+   | _WRITE    | u64m      | MUST be | MUST be <=  | MUST be u64m      |
+   |           |           | _WRITE  | loga_offset |                   |

Same as above.  It's true files and objects layout can provide
such write layouts, but blocks will need an infinite Turing tape machine
or like to do that :)

Not that it makes sense for the client to *require* write layout that
stretches out to infinity, but it can just mean a write layout to
the *current* EOF, wherever it is and the server can extend that
to infinity in the reply if it can and wants to.

+   | _WRITE    | < u64m    | MUST be | MUST be <=  | MUST be >=        |
+   |           |           | _WRITE  | loga_offset | loga_offset -     |
+   |           |           |         |             | layout offset +   |
+   |           |           |         |             | loga_minlength    |
+   +-----------+-----------+---------+-------------+-------------------+

Putting it an overly-narrow table is very hard to read.

How about defining the basic rules like this?

returned offset MUST be <= loga_offset.
returned length MUST be > 0.
returned offset + length SHOULD be >= MIN(loga_offset + loga_minlength, NFS4_UINT64_MAX)

[I'm still not comfortable with MUST for return offset + length since
it seems to me we haven't anticipated all corner cases.]

With the following exceptions:
   1. The argument loga_minlength is set to NFS4_UINT64_MAX.

   2. The argument loga_iomode was set to LAYOUTIOMODE_READ, and
      loga_offset plus loga_minlength goes past the end of the file.

Benny

> 
> Links:
> 
> http://eisler.com/nfsv4-wg/2008-05-04-ch-19-20.html
> http://eisler.com/nfsv4-wg/2008-05-04-ch-19-20.txt
> http://eisler.com/nfsv4-wg/2008-05-04-ch-19-20_cvs_src.txt
> 
> 
> On Sat, May 3, 2008 7:07 pm, Mike Eisler wrote:
> > This includes all elements of my loga_length and loga_minlength proposal,
> > except for allowing loga_minlength to be zero. Waiting on more feedback
> > before
> > declaring rough consensus.
> 
> 
> 
> -- 
> Mike Eisler, Senior Technical Director, NetApp, 719 599 9026,
> http://blogs.netapp.com/eislers_nfs_blog/
> 
> 
> 
> _______________________________________________
> nfsv4 mailing list
> nfsv4 at ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
> 

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

---

From: "Mike Eisler" <[email-masked]>
Date: Mon, 5 May 2008 08:18:24 -0700 (PDT)

> Can we discuss that during the connectathon?

People need to express their preference on this list
in order for rough consensus to be declared. And
my hope is to give this spec to the Area Advisor before
I show up at Connectathon a week from today.

My proposal is that that min_length == 0 mean the
opportunistic layoutget. We've heard from
most implementors. Most of those have agreed
with the proposal.

> would like to identify himself: feel free to... :)

I've thought of the same thing, and was about to do that until
I realized that by actually defined loga_minlength in a way that
doesn't make it useless, we don't need to do that.

> +    Acceptable layouts based on loga_minlength (u64m = NFS4_UINT64_MAX)

Agreed.

> 2) Why the requirement for _RW?

It says "MAY be _WRITE". No requirement at all.

>    Why not to the current EOF as in the READ case?

Because the client requested a minlength of ^64-1 and the server is
returning an iomode of _WRITE. So the layout is 2^64-1. If this is
a problem, return an error.

This is consistent with the other row that
returns a _RW layout with minlength of 2^64 - 1.

> such write layouts, but blocks will need an infinite Turing tape machine

Then blocks can return an error. And the block's RFC can provide
more advice.

> Not that it makes sense for the client to *require* write layout that

It makes perfect sense to me, especially for holey files.

> the *current* EOF, wherever it is and the server can extend that

So now you want to redefine a layout loga_minlength request of
NFS4_UINT64_MAX to mean the current EOF?

How does the client ever extend the file?

> +   |           |           |         |             | loga_minlength    |

The narrowness is a function of the medium: 80 character wide text.

We'll look into a PDF version of the RFC and see how that
displays. Also, I think I can make it more readable with more
abbreviating. Meanwhile, there is always the HTML version of the spec
which is what I would write code from anyway. I'll post the full
.html in my next iteration today.

> returned offset + length SHOULD be >= MIN(loga_offset + loga_minlength,

You don't think that combining the offset and length in that manner
has less clarity? Which row in the table does the above
correspond to?

> it seems to me we haven't anticipated all corner cases.]

Then return an error. If the client doesn't like errors, it can set
minlength to 1. The server will increase this to a value that
makes sense for it.

The problem with underspecified fields like loga_length,
loga_minlength, and loga_offset, is that they are underspecified.
I can easily imagine that when one attempts to actually
specify what they do, this is going to cause problems for
people with different interpretations. Text like:

"The client MUST be prepared to get a layout that does not
 align exactly with its request"

doesn't say anything useful. I'm sympathetic, but
these fields were underspecified for years, and if we don't
get rigorous now, when will we?

---

From: Benny Halevy <[email-masked]>
Date: Mon, 05 May 2008 19:57:34 +0300

> most implementors. Most of those have agreed

I agree with that too.

Benny

> returns a _RW layout with minlength of 2^64 - 1.

True.  I think both are too restrictive.

> NFS4_UINT64_MAX to mean the current EOF?

No, I do not want to redefine it, but when you make a small blanket
by having hard restrictions on the returned layout length,
when you pull it to cover your head, your feet just get exposed...
Previously if the client requested a RW layout and passed
loga_length := u64m I'd return it a "finite" layout limited to the
current EOF.  Having to return NFS4ERR_BADLAYOUT if I can't
give out RW layouts with length==u64m creates an interoperability
nuisance IMO.

> How does the client ever extend the file?

It asks for a RW layout, with loga_offset and loga_length that
cover the byte range it wants to write to and loga_minlength describing
it's I/O size constraints.

> has less clarity? Which row in the table does the above

I think the describing the requirement fro the returned offset + length
is clearer than describing the requirement for the returned length.
Note that you subtract "layout offset" in all cases where layout
length != u64m.

> minlength to 1. The server will increase this to a value that

True.  But the client already has to be prepared to get a layout
for a range that ends at an offset that is less than loga_offset +
loga_minlength for the exceptions we listed.

My concern is that it is possible likely that there are
other, unforeseen, cases that will cause the server to return
an error and will require the client to handle it (if the
error handling is implemented), while the client is already
required to implement the "short layout" case anyway and can
reuse the same logic for the cases that are pathological
for the server.

Let me try to describe the example I badly portrayed in an
earlier message:

The stripe size is 1MB.
client A holds a write layout for offset 1MB length 2MB
client B requests a write layout for offset 0 minlength 2 MB.

Our server's constraint, due to clients performing RAID
over objects is that only one client can hold a write layout
for a specific stripe at a time, so to satisfy client B's
request in full I need to recall client A's layout.

What I would like to do for optimal pipelining of I/O
is return a layout for the first stripe (offset 0, length 1 MB)
to client B, and send an asynchronous recall to client A's
to hopefully achieve parallel I/O while both A and B are writing
to storage in parallel.  When B will be done with the first stripe
it will ask for the second one.

With the restrictions you're suggesting, and with a badly
implemented client that asks for too big of a loga_minlength
client B will get screwed since it will have to wait for client A
to return the layout it holds.

> get rigorous now, when will we?

I agree that this sentence by itself is useless.  We required
intersection with the requested layout, and it too wasn't
enough, and all this needs to be improved.

Benny

---

From: "Mike Eisler" <[email-masked]>
Date: Mon, 5 May 2008 12:33:11 -0700 (PDT)

> give out RW layouts with length==u64m creates an interoperability

The client can for example send:

       loga_minlength = 1
       loga_length = NFS4_UINT64_MAX
       loga_offset = 0

and your server can return a finite amount between 1 and 2^64 - 2 if it
wants.

Let's say disallow NFS4_UINT64_MAX (2^64 - 1) as being a valid value for
loga_minlength. So what if the client sends a request with loga_minlength
== 2^64 - 2?

It sounds like you don't want a positive loga_minlength
to mean anything, and instead allow the server to return
whatever length it wants. If so, then:

1. Why have loga_minlength?
2. What if the layout the server returns is useless to the client?

The client knows what it wants; it knows it has a pending read() or
write() system call that has offset loga_offset and loga_minlength. If
we are going to allow short layouts, we will have a larger interop
nuisance.

> to infinity in the reply if it can and wants to.

Again, if a loga_minlength to NFS4_UINT64_MAX means return
  " write layout to the *current* EOF, wherever it is"
how, does the client ever extend the file?

> Note that you subtract "layout offset" in all cases where layout

LAYOUTGET and layouts
should have been specified in in terms of start and begin
offsets, but they are what they are. Since they are lengths,
then I think invariants need to be returned in lengths one side
of the relation. I'm not happy to provide algebra, solve for x
word problems to our readers.

> loga_minlength for the exceptions we listed.

We allow the server to return a layout that fully includes the range
expressed by [begoff = loga_offset, endoff = loga_offset+loga_minlength-1]
The returned end offset can be higher than that requested. The returned
beg offset can be lower than what was requested. I do not understand
why you compare getting a begin offset less than was what asked for
to getting an end offset that is less than what was asked for.

> reuse the same logic for the cases that are pathological

There will always be interoperability bugs. But number of such bugs are
fewer when there are invariants annotated with MUST, REQUIRED, etc.

> request in full I need to recall client A's layout.

Does client B actually need 0 through 2 MB, or does it need
0 through 1MB - 1? If so, B should send:

 - loga_offset = 0
 - loga_minlength = 1MB
 - loga_length = 2 MB

And here is a rebuttal example:

The stripe size is 1MB.
client A holds a write layout for offset 0 length 1MB
client B requests a write layout for offset 0 minlength 1MB.

Now what are you going to do?

You could recall client A's layout, but what if it immediately
issues LAYOUTGET for [0, 1MB]?

Or you can return an error.

> it will ask for the second one.

How do you know the client can do anything with [0, 1MB]?
The way to tell is for the client to provide two ranges, which in
the proposal is covered with loga_minlength and loga_length.

> to return the layout it holds.

Or you reject loga_minlength's that you think are too big, and the
client tries a smaller one.

---

From: Robert Gordon <[email-masked]>
Date: Mon, 05 May 2008 15:23:57 -0500

> The dot-x definition will change but the on-the-wire format won't

It seemed the least harmful dot-x change.. and most obvious..

err.. it was me :-)

Robert..

---

From: Benny Halevy <[email-masked]>
Date: Tue, 06 May 2008 00:54:46 +0300

> loga_minlength. So what if the client sends a request with loga_minlength

Not exactly.  I want loga_minlength to be a hint that the server SHOULD
try to satisfy.

> 1. Why have loga_minlength?

To optimize layout retrieval.

> 2. What if the layout the server returns is useless to the client?
If the client can split the I/O it should do it with the layout it got
then ask for a layout for the rest of the range, rinse, wash, repeat.
Oh but then it is not useless, so let's move on.

If the client can't split the I/O, then it can ask for the layout for the
remainder of the range and see if it can merge it.
If it fails to get or merge the adjacent layout or doesn't want to,
it should courteously return the layout and the the I/O via
the MDS.

> write() system call that has offset loga_offset and loga_minlength. If

The I/O data range should have offset loga_offset and length loga_length.
loga_minlength should be the absolute minimum size useful for the client,
e.g., one byte, one sector, or one memory page.  If the client sends some
bigger number he thinks is good for performance it is likely to hit the 
server and
layout type topology constraints.  I'm not saying it is unrecoverable, 
since the
client can back off from the performance-optimized value to lower values
or do the I/O via the MDS.

> we are going to allow short layouts, we will have a larger interop

We already allow that, when you hit EOF on read.

> how, does the client ever extend the file?

In this case loga_length should NFS4_UINT64_MAX not loga_minlength, like 
I said
above.  Anyhow, for our server the client must give us the real number 
of bytes it wants
to write otherwise it will get an error as we don't provide read/write 
layouts that stretch to
infinity, we only allow that for read layouts.

> word problems to our readers.

OK.

> to getting an end offset that is less than what was asked for.

I'm not sure why you think I compared the two...
The client has to be prepared to get less than it requested for the "EOF 
on read" case.

> fewer when there are invariants annotated with MUST, REQUIRED, etc.

Not being able to do pNFS because the server *complies* with over-strict 
requirements
is not an interoperability bug, it's simply a design flaw IMO.  Maybe 
I'm being too cautious
about it...  The guidance to the client should be "use the smallest 
useful value for
loga_minlength and consider backing off if it proves to be too high".

> Or you can return an error.

I'll recall the layout and arbitrate between the two by sending
a NFS4ERR_TRYLATER to the immediate attempt by client A,
and register a notification if A asked for it (which I hope it would).
Recalling the layout from B at some point in the (near) future
should allow be to perform it's I/O commit it and gracefully
return the layout for A's turn.

> client tries a smaller one.

That's possible.
Let's go for it and I'll keep my fingers crossed and my mind active 
about that.
Just I ask for adding a paragraph recommending something like:
    The client SHOULD set loga_minlength to the smallest value it could use,
    e.g., page_size - (loga_offset modulo page_size).  If it chooses to use
    initially set loga_minlength to a higher value, e.g., for 
performance reasons,
    the client SHOULD be prepared to back off loga_minlength to a 
smaller value
    if the server cannot provide such a layout.

Benny

---

From: Robert Gordon <[email-masked]>
Date: Mon, 05 May 2008 17:17:45 -0500

> Not exactly.  I want loga_minlength to be a hint that the server  

wow!

I've been seeing it as a MUST.

loga_offset + loga_minlength is the byte-range the client
needs to write to. anything else the server returns is gravy..

Robert..

---

From: Robert Gordon <[email-masked]>
Date: Mon, 05 May 2008 17:22:46 -0500

> loga_minlength should be the absolute minimum size useful for the  

so that means (to me) that loga_minlength is a MUST !

Robert.

---

From: Robert Gordon <[email-masked]>
Date: Mon, 05 May 2008 17:48:21 -0500

> needs to write to. anything else the server returns is gravy..

-1 of course..

Robert.

---

From: Benny Halevy <[email-masked]>
Date: Tue, 06 May 2008 02:07:18 +0300

>> needs to write to. anything else the server returns is gravy..

So what's loga_length for?
The essence of the original text, as I interpreted it was that the client
should be ready to fetch the layout and do the I/O in segments and that
loga_minlength is an optimization to be used for performance.
Now that it becomes a mandatory requirement for the server it must be taken
into account for correctness.   If you need to write to (or read from)
some large byte range, do you have to have the layout covering *all*
of it at one point in time?  Or can you split the I/O, e.g. using a sliding
window of one data server / stripe unit at a time?  Can you *possibly*
do that one page at a time?
If the one-page-at-a-time is feasible, even if sub-optimal, you want
to allow it for the corner cases the server might get into so you may do
do zillion petabytes of I/O with a small fraction of it done in 4 KB
chunks and the most of it with the beefy layouts the (still sane and
performance aware) metadata server will give you.

Benny

---

From: "Mike Eisler" <[email-masked]>
Date: Mon, 5 May 2008 16:30:06 -0700 (PDT)

> So what's loga_length for?

That's what I'd like you to answer. In the my proposal,
loga_length+loga_offset-1 is the desired
end offset of the range of layout.

> loga_minlength is an optimization to be used for performance.

I can't tell what you think loga_length and loga_minlength were for in
draft-22.

I can't tell what you think loga_length should for after draft-22.

---

From: Robert Gordon <[email-masked]>
Date: Mon, 05 May 2008 18:32:58 -0500

> So what's loga_length for?

I see loga_length as the hint. The client anticipates that it will  
perform
IO to loga_offset + loga_length -1, but only has the immediate need for
the first page loga_length + loga_minlength -1;

Stating that log_minlength as a MUST means that the server will return
an error, and it is then up to the client to adjust the value of
loga_minlength to a smaller value.

Mike, is that what you had in mind ?

Robert.

---

From: "Mike Eisler" <[email-masked]>
Date: Mon, 5 May 2008 16:57:59 -0700 (PDT)

> Mike, is that what you had in mind ?

Yes that represents what I sent out on Sunday and posted to eisler.com.

---

From: "Mike Eisler" <[email-masked]>
Date: Mon, 5 May 2008 20:54:24 -0700 (PDT)

http://eisler.com/nfsv4-wg/2008-05-05/

cleans up the nits that have been reported.

I'm not planning on doing anything more with LAYOUTGET until
we declare a rough consensus on the contentious issues:

- what do loga_length, loga_offset, loga_minlength mean?
- what are the requirements of the server with respect to
  these values?

Paradoxically, we have perfect consensus that if loga_minlength=0,
the server can return a layout of any length as long as it starts at
or before loga_offset. But to add the text requires answering the above
to questions. My answers are in http://eisler.com/nfsv4-wg/2008-05-05/

I'm going to move on to chapter 21.

---

From: Benny Halevy <[email-masked]>
Date: Tue, 06 May 2008 07:20:53 +0300

> Yes that represents what I sent out on Sunday and posted to eisler.com.

So we're all in agreement then.

Benny

---

From: Benny Halevy <[email-masked]>
Date: Tue, 06 May 2008 07:26:42 +0300

> I can't tell what you think loga_length should for after draft-22.

This is getting really frustrating,
I was asking Robert what in his understanding of loga_length is 
according to this

>> needs to write to. anything else the server returns is gravy..

The combination of "loga_minlength" and "*the* byte-range the client 
needs to
write to" got me alarmed as Robert probably meant or should have meant 
to refer
to loga_length and not to loga_minlength.

Benny

---

From: "Mike Eisler" <[email-masked]>
Date: Mon, 5 May 2008 21:40:34 -0700 (PDT)

On Mon, May 5, 2008 9:26 pm, Benny Halevy wrote:
hat you think loga_length and loga_minlength were for in
> This is getting really frustrating,

What's frustrating is that we've set a new record in
low TTL for a rouch consensus: 6 minutes.

> to loga_length and not to loga_minlength.

No he means loga_minlength.

Again: is your issue that you want to swap the meanings
of loga_length and loga_minlength from what is there in
   http://eisler.com/nfsv4-wg/2008-05-05/
?

---

From: Robert Gordon <[email-masked]>
Date: Tue, 06 May 2008 00:40:54 -0500

> No he means loga_minlength.

correct.

Robert.

---

From: Benny Halevy <[email-masked]>
Date: Tue, 06 May 2008 08:41:48 +0300

>    http://eisler.com/nfsv4-wg/2008-05-05/
No, not at all.
There's no need to swap the meanings of loga_length and loga_minlength in

If we have such a rough time understanding each other, how
about adding an example?

Off the top of my head:

A client receives a read from the application for offset 5000
count 4000.  The client's page size is 4096 bytes and its
I/O should be page aligned.  The client should set
loga_offset = 4096
loga_length = 8192
loga_minlength = 4096

Are we in agreement on that?

Benny

PS: I have to leave for the airport now and hope to continue the discussion
on the road, or when I arrive in CA on Wednesday (very late Tuesday night
actually)

---

From: Benny Halevy <[email-masked]>
Date: Tue, 06 May 2008 08:48:02 +0300

> I/O should be page aligned.  The client should set
one small correction (very bad idea to do all that when I'm in a hurry... :)
although the client may want to do that, for the sake of giving a good 
example
to discuss, I'd like to say
loga_length - 4904
so it will extend exactly to the I/O range.

---

From: "Mike Eisler" <[email-masked]>
Date: Mon, 5 May 2008 22:50:29 -0700 (PDT)

> I/O should be page aligned.  The client should set

Yes the above would be a rational use, and if we've got
agreement, I'll add text to LAYOUTGET
that recommends page aligned offsets and
lengths in arguments and results.

---

From: Benny Halevy <[email-masked]>
Date: Tue, 06 May 2008 08:54:15 +0300

>> No he means loga_minlength.

You go me really confused now, since in
http://www.ietf.org/mail-archive/web/nfsv4/current/msg05983.html
you said "The client anticipates that it will perform IO to loga_offset
+ loga_length -1, but only has the immediate need for the first page 
loga_length
+ loga_minlength -1"
with which I agree.

Benny

---

From: Robert Gordon <[email-masked]>
Date: Tue, 06 May 2008 01:27:11 -0500

> + loga_length -1, but only has the immediate need for the first page  

using your earlier example.

"A client receives a read from the application for offset 5000
count 4000.  The client's page size is 4096 bytes and its
I/O should be page aligned. "

I would expect a client to construct :-

	loga_offset 	= 4096;
	loga_minlength	= 8192;
	loga_length     = 24576;

The client wants to read offset 5000 for a count of 4000;
loga_offset + loga_minlength satisfies reading the file
from 5000 -> 8999; The client knows that it is doing
read-a-head, and would be okay if the server could
return 6 pages rather than 2 pages, but it MUST have
2 pages to satisfy the application read.

Robert..

---

From: [email-masked]
Date: Tue, 6 May 2008 11:01:33 -0400

I agree with Robert as to the expectations of what the client will send.

I'd like to send another example though which shows support for Benny's
thought that the client may send loga_minlength smaller than the
application I/O size.  For example, assume the application has done a
write system call with offset 0, and length 32M.  (If this does not seem
large, increase it to 1G).  The client implementation may need to will
issue this as several I/Os to the data server and thus would generate a
LAYOUTGET for the first "chunk".  E.g.

loga_offset = 0
loga_minlength = 1M
loga_length = 16M

If the server can supply 16M of layout, that is great, but the client
has decided that even a layout of length 1M is sufficient to start the
process.  Also, if the client has detected sequential I/O, it might set
loga_length to even greater than 16M in an effort to be ready for the
next I/O from the user.  The server, if it detected sequential I/O
should also be capable of supplying more than 16M if doing so is
convenient,  and likely to avoid a future LAYOUTGET operations.

-Jason

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Robert Gordon
> Sent: Tuesday, May 06, 2008 2:27 AM
> To: Benny Halevy
> Cc: NFSv4
> Subject: Re: [nfsv4] wordsmithing for chapters 19-20
> 
>

---

From: [email-masked]
Date: Tue, 6 May 2008 11:06:16 -0400

I disagree with your suggestion of adding text to recommend page aligned
offsets in arguments and results.  

So far the protocol has avoided any mention of page sizes, and I think
that entirely appropriate.  Some machines have 4K pages, others 16K.
This is just a detail of the client platform implementation.

-Jason

Of
> Mike Eisler
> Sent: Tuesday, May 06, 2008 1:50 AM
> To: [email-masked]

---

From: "Mike Eisler" <[email-masked]>
Date: Tue, 6 May 2008 08:17:20 -0700 (PDT)

If I suggested power of 2 alignment and sizes, I'm sure someone
would complain about that too.

At this point I have no clue what it is people want, and more
importantly I don't care. The role of nit picking in delaying this
specification is over.

I will write a modified version of LAYOUTGET today and post it to
eisler.com.

---

From: [email-masked]
Date: Tue, 6 May 2008 11:19:18 -0400

Yes, so I think that means do not change it (i.e. do not add the text).
-Jason

Of
> Mike Eisler
> Sent: Tuesday, May 06, 2008 11:17 AM
> To: [email-masked]

---

From: "Halevy, Benny" <[email-masked]>
Date: Tue, 6 May 2008 19:04:06 -0400

If the client wants to read ahead it should ask for an
appropriate range as you noted below.  It doesn't matter
to the server why the client wants to do the I/O.

Regarding loga_minlength, you're basically proving my concern
that client implementations will tend to use higher values
for it since they don't want to break their I/Os
and potentially sweep through the range they must read from
or write to using more than one layout segment.

If this is not implemented in your client, then you should
ask for such a minlength as it represents you minimum.
If you can split the I/Os you can start with a high value
and back off if the server can't give it to you or just
start with your minimum minimum trusting that the server
is likely to give you a layout covering at least <loga_offset,
loga_length> as it SHOULD.

Benny

-----Original Message-----
From: Robert Gordon [mailto:[email-masked]]
Sent: Tue 2008-05-06 09:27
To: Halevy, Benny
Cc: NFSv4
Subject: Re: [nfsv4] wordsmithing for chapters 19-20

	loga_offset 	= 4096;
	loga_minlength	= 8192;
	loga_length     = 24576;

Robert..

---

From: Robert Gordon <[email-masked]>
Date: Tue, 06 May 2008 19:56:04 -0500

I think we're strongly stating the same thing :)
and i think that we are in agreement as the meaning
of minlength and length..

altering my use of your example, but using the
method you said below.. (assuming the client wants
4k chunks) -- your expectation is that a client
would issue..

	loga_offset 	= 4096;
	loga_minlength	= 4096;
	loga_length     = 8192;

loga_offset + loga_minlength satisfies the 3191 bytes
for the first IO segment.. and loga_offset + loga_length
covers the entire 4000 bytes..

Robert..