checked in a new pnfs chapter into cvs.

Depdns what you mean by "go there".  I think it would
be hard (and not really well-motivated) to require
that the handles be the same.  After all I could have
two different devices (and thus two filehandles for 
stripes) and after a restriping due to device failure
or other reconfiguration wind up with two stripes on
the same device.

I don't think the example should include that kind
of wierdness though.

I think update_data should be lou_data.  I'm supposing
that this used to be called update_data but when I went
to previous drafts, I foudn it was called layoutupdate_data
in drafts 3 and 4.  Maybe it was called update_data in 0, 1,
or 2.

Maybe sparse and sense are not the right words for this.  They
seem to be causing confusion.

In each case, there are (or maybe may be is better), blocks
for each block of the original file.  In that sense, the
sparsity or density of the mapping is not at issue although
the sparsity or density of the file itself may be.

Perhaps the right terms are "direct" (for what was spare)
and "compacted" (for what was dense).

In a direct mapping block X of the original file always 
maps to block X of the individual stripe files.  If there
are two individual stripe files, then each of thse files
is sparse (in the normal sense) since only half the block
displacement are used.

In a compacted mapping each block of the stripe file is
filled in assuming the original file being mapped is dense.
So if I have blocks 0, 2, 4, 6,. etc going to stripe zero,
stripe zero has corresponding blocks 0, 1, 2, 3, while
blocks 1, 3, 5, 7 of the original file correspond to 
blocks 0, 1, 2, 3 of stripe one.

I don't knwo how one would use something non-determnistic
here.

In any case, that is the current model, that it is gotten from
GETDEVINFO.

If there is some reason that a client would have to know earlier, then
we 
will have to change things.

In this case, I'm not sure the client needs to know before it resolves 
the device ID. Once it resolves the device ID (e.g., through GETDEVINFO) 
it knows since it is a switched union.

-Garth

Mike Eisler "NFSv4.1 Issue Tracker" wrote:
> Mike Eisler <email2mre-ietf@yahoo.com> added the comment:
> 
> How does a client learn where a deviceid refers to a COMPLEX or
> SIMPLE device (maybe we should just reserve the high order bit
> to indicate this)?
> 
> In addition, how does a client determine the list of simple devices
> the a complex device maps to?
> 
> ____________________________________________________________
> "NFSv4.1 Issue Tracker" <issue-tracker@nfsv4-editor.org>
> <http://www.nfsv4-editor.org/cgi-bin/roundup/nfsv4/issue156>
> ____________________________________________________________

Define a layouthint_data type and describe it in the data types section.

Define an explcit device_addr type and describe it in the data types
section.

By doing this, it will become clearer that various address fields are.

Possible typo in GETDEVINFOINFO op description?

It says:
  The device address MUST correspond to the layout 
  type specified by the GETDEVICELIST4args.

Should this be GETDEVICEINFO4args?

How does a client learn where a deviceid refers to a COMPLEX or
SIMPLE device (maybe we should just reserve the high order bit
to indicate this)?

In addition, how does a client determine the list of simple devices
the a complex device maps to?

The dev_list example seems to be saying that the save device
id for the same file have different data server file handles. Do we really
want to go there? .... example follows:

 Within the nfsv4_file_layouttype4, imagine a "dev_list" constructed of <device
ID, device index, FH> tuples:

dev_list = [<1, 0, 0x12>, <2, 0, 0x13>, <3, 0, 0x14>, <4, 0, 0x15>]

And a "stripe_devs" array containing the following indices:

stripe_devs = [2, 3, 0, 1]

Using the stripe_devs as indices into the dev_list, we get the following ordered
list of nfsv4_file_layouts:

[<3, 0, 0x14>, <4, 0, 0x15>, <1, 0, 0x12>, <2, 0, 0x13>]

Continuing to flatten the Complex devices gives us the following list of 5
simple <device ID, FH> tuples. Note device 2 is a Complex device that gets
replaced with devices 3 and 4:

[<3, 0x14>, <4, 0x15>, <1, 0x12>, <3, 0x13>, <4, 0x13>] 

---------------

In the last list, I believe the first field is the deviceid, and
the second is the file handle. So device 3 has filehandles 0x14
in the first entry and 0x13 in the second to last entry.

The layoutupdate4 description refers to a non-existing field:

         The contents of the opaque lou_data argument are 
         determined by the layout type and are defined in 
         their context. The NFSv4 file-based layout does not use 
         this structure, thus the update_data field should have a 
         zero length.

There is no update_data in the layoutupdate4 struct. Nor is there any
where in drsaft-08 or its .x file.

The explanation of sparse striping is lacking.

Dense seems to be that every possible block of the
file across all data servers is filled.

Sparse seems to be that only one block in each
data server at a particule offset on the file
in data server is filled, and the data server that
gets the filled block is selected in round
robin (i.e. a form of determinism) for each offset (each round
in other words).

I'm more familiar with "sparse" meaning
that only a small, non-determinisitic subset of the
table has entries. 

If the sparse striping is deterministic, that begs the question
why there isn't a non-determinisitic way to stripe sparse files,
because that would seem to be useful.

The sparse and dense examples should also show the corresponding
logical file, and how each logical block maps to the blocks in the
data server.

The spec notes 

The "stripe_devs" array contains a list
    of indices into the "dev_list" array; an index of zero specifies
    the first "dev_list" entry.  Each successive index selects a
    "dev_list" entry whose file handle and device id are to be used
    next in sequence for that stripe.  This allows an arbitrary
    sequencing through the possible devices to be encoded compactly.
    When the "stripe_devs" array is of zero length, the elements of the
    "dev_list" array are simply used in order, so that the portion of
    the stripe held by the corresponing entry is determined by its
    position within the device list.

But what if striple_devs is of non-zewro length and smaller than dev_list?

The dev_lsit array example  needs to include multiple complex devices, and also
some complex devices with index fields that are not zero.