Subject: Re: [nfsv4] proposal for loga_length and loga_minlength

From: "Mike Eisler" <[email-masked]>
Date: Sun, 4 May 2008 19:32:41 -0700 (PDT)

On Sun, May 4, 2008 3:56 am, Benny Halevy wrote:
> On May. 02, 2008, 21:30 +0300, "Spencer Shepler" <[email-masked]>
> wrote:
>> On May 2, 2008, at 1:21 PM, Mike Eisler wrote:
>>
>>> Problems:
>>>
>>> - loga_minlength as specified is useless
>>> - the rules for when a server can return a layout of a range that
>>>   is a super-set, sub-set, intersection, ... of the requested range
>>>   (loga_offset, ... loga_offset + loga_length - 1) are unclear
>>>
>>> - Some people have expressed a desire for an "opportunistic" LAYOUTGET
>>>   that returns a layout if the amount of overhead on the pNFS
>>> server is
>>>   minimal (e.g. if it does not require provisiong storage devices
>>> and/or
>>>   space on storage devices).
>>>
>>> Proposal:
>>>
>>> - The layout returned MUST have an offset that is no higher than
>>>   loga_offset
>
> like I previously said here:
> http://www.ietf.org/mail-archive/web/nfsv4/current/msg04948.html
> I think that the returned range should cover loga_offset but
> not necessarily start at it, since the server may want to align
> the starting offset differently.

You wrote in that link:
  But I'd still prefer to require that the returned layout MUST
  cover the requested offset, i.e.:
   lo_offset <= loga_offset &&
   lo_offset + lo_length >= loga_offset + ((loga_length != 0) ? 1 : 0);

The first part of the local express agrees with my proposal.

The second part seems to say that a zero length layout is permitted,
which I don't see a need for. Now we've allocated a stateid, and
have to recall a zero length object that consumes memory. Not
a healthy situation.

It also seems to say that
 - if loga_length > 1, then a layout of length
   1 can be returned. Under my proposal, this would be done by setting
   loga_minlength to 1, and loga_length to any value >= 1.

- a layout that does not completely include the requested layout can
  be returned. E.g. loga_offset=100, loga_length=1000. The server could
  return in a logr_layout array of length 1:
    lo_offset=10
    lo_length=600

    lo_offset (10) <= loga_offset (100)
    lo_offset + lo_length (610) >= loga_offset + 1 (101)

  My proposal would allow you to do:

    loga_minlength = 1
    loga_offset = 100
    loga_length = 1000

  and the server would be permitted to return:
    lo_offset (10) <= loga_offset (100)
    lo_length (600) >=
     loga_offset - layout offset + loga_minlength 100-10+1= 91

>>> - The layout returned MUST have a length that is no smaller than
>>>   loga_minlength.
>
> I'm sort of OK with that, although I'd be happier with a SHOULD
> rather than MUST.
>
> If, for alignment reasons logr_offset < loga_offset and assuming,
> as you mention below that the client requires the range
> log_offset to log_offset + loga_minlength (non-inclusive)
> than the returned lo_offset + lo_length SHOLUD be >=
> loga_offset + loga_minlength.
> But for the same alignment constraints lo_length might be shorter.

The total layout has to at least as long as loga_minlength, actually
loga_offset - layout offset + loga_minlength.

If the server can't return a layout that long, then it returns
an error. The client can always ask for a loga_minlength of 1. If
that's a problem, the server can return an error.

>
> Now that the logr_layout is an array, the server can describe
> the rest of the region in the next entry, but:
> a. loga_maxcount must be large enough... and that concerns me
> especially with widely striped files, and

We have an error to convey that loga_maxcount is too small.

> b. The layout for the next stripe or group of stripes may be
> held by another client and I would like to do the CB_LAYOUTRECALL
> to the other client concurrently with this client's I/O.

I don't understand:

- how you can recall a conflicting layout in parallel with allowing
  I/O

- Even if you can do that, what that has to do with your proposal.

> In summary, the client doesn't have to use the layout and can
> return it and stop asking for more layouts if it doesn't like the
> layouts the server gives it, so IMO loga_minlength should be
> treated as a hint rather than a hard requirement, otherwise, I
> anticipate clients will reduce it to something quite small,
> e.g. 1, or one page size.

The hint is loga_length.

The required length is loga_minlength.

The field loga_minlength MAY be zero (0). If it is zero,
the client is indicating it desires a layout of length loga_length (1
or more), and the server return such a layout or not, at the
specified offset. The server is free in that case to return a
layout of any offset <= loga_offset of any length, 1 or more.

So how doesn't that meet your needs?

>>> - loga_length MUST be >= loga_minlength
>
> That makes sense.
>
>>>
>>> - loga_minlength MAY be zero (0).
>
> I like that too (well, I need to be consistent with what I
> suggested myself in the past ;-).

Hmm, I can't tell if you agree with the proposal or not.

-- 
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: Benny Halevy <[email-masked]>
Date: Mon, 05 May 2008 17:01:03 +0300

Sorry for the late response.  I had trouble with my email...

On Sun, 04 May 2008 12:54:38 -0500, Robert Gordon wrote:
> On May 4, 2008, at 5:56 AM, Benny Halevy wrote:
> the current wording is such that there is only one element
> in the array when there is a single stripe pattern.
> 
> are you saying that we should change that ??

First, "striping pattern" is essentially a files-layout specific term
and it doesn't seem like a good idea to use it as it is in LAYOUTGETs
description.

Secondly, this is described in a bit more permissive words:
   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.

In the example I gave the layout will straddle two objects stripe groups,
which are not, strictly speaking, "striping patterns", but in essence
I think they fall in the same category as meant in the paragraph you
mentioned.

The bottom line is that I can live with the current text.
If we do change it, just let's not be too anal about how the server
should sub-divide the layout within the array.

More than that.  I'd gladly get rid of this array if only we'd be
willing to be less strict about the returned range with respect to
loga_minlength so if the server needs an array to describe the layout
in the required range, it could just return a layout for a smaller
range and the client can ask for the rest.

Benny

> Robert..
> nfsv4 at ietf.org