Subject: Re: [nfsv4] File Layout change proposal

From: "Anatoly Pinchuk" <[email-masked]>
Date: Fri, 7 Dec 2007 11:51:39 -0800

This is simplification of the file layout solution I proposed earlier.
Main goals are

-        Resolve the file layout issues as soon as possible since we
need I-D ready for the WG last call

-        Keep changes to minimum

-        Make sure that the protocol layout structures and file layout
ones in particular are compact, consistent and flexible. Then variety of
client/server implementations can benefit from such layout definitions
by utilizing appropriate mapping.

Let us start with summary of proposed changes

-        LAYOUTGET4resok structure contains layout4 structure, not array

-        nfsv4_1_file_layout4 structure is renamed into
nfsv4_1_file_layout_segment4

-        field nfls_off field is added to the
nfsv4_1_file_layout_segment4 structure

-        nfsv4_1_file_layout4 is re-defined as array of
nfsv4_1_file_layout_segment4

-        Number of data file handles in nfls_fh_list array is not linked
to packing and can be equal to 0, 1, number of elements in
nflda_stripe_indices array, or number of elements in
nflda_multipath_ds_list array.

Here are the updated structures and fields description.

struct LAYOUTGET4resok {

            bool                 logr_return_on_close;

            stateid4            logr_stateid;

            layout4            logr_layout;

};

struct nfsv4_1_file_layout_segment4 {

            deviceid4        nfls_deviceid;

            offset4             nfls_off;

            nfl_util4           nfls_util;

            uint32_t           nfls_first_stripe_index;

            nfs_fh4            nfls_fh_list<>;

};

nfls_off

Offset of first byte of the client file the file layout segment is
applicable to.

nfls_fh_list

An array of data server file handles. Once we mapped the handle into
nflda_multipath_ds_list, it is used for all data servers in the list.
The mapping of handles into the lists is defined below. Number of
elements in nfls_fh_list MUST be

- Zero means that the data file handles used for each data server list
MUST be the same as the one returned by the OPEN operation from the
metadata server.

- One element in the list means that each data server MUST use the same
file handle what is specified in nfls_fh_list[0].

- The number of elements as nflda_multipath_ds_list array. Thus, in this
case, when issuing an I/O to any data server in
nflda_multipath_ds_list[nflda_stripe_indices[X]], the filehandle in
nfls_fh_list[nflda_stripe_indices[X]] MUST be used.

- The number of elements as in nflda_stripe_indices array. Thus, in this
case, when issuing an I/O to any data server in
nflda_multipath_ds_list[nflda_stripe_indices[X]], the filehandle in
nfls_fh_list[X] MUST be used.

typedef nfsv4_1_file_layout_segment4 nfsv4_1_file_layout4<>;

-Anatoly

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

---

From: Mike Eisler <[email-masked]>
Date: Fri, 7 Dec 2007 13:41:44 -0800 (PST)

> nfsv4_1_file_layout_segment4 structure

After creating a spreadsheet and running some scenarios,
I came to the same conclusion that Garth and you have.

However nfls_off is better described as the first logical file offset
the striping pattern described in the nfsv4_1_file_layout_segment4
> nflda_multipath_ds_list array.

How can that be true? For example, if we are using dense packing,
and the striping pattern stripes over the same data server two or
more times, we need two or more filehandles. So if nfls_fh_list
is zero length, why won't we get corruption?

> nfls_fh_list[X] MUST be used.

What if the number of elements in nflda_multipath_ds_list equals 
nflda_stripe_indices? Which filehandle gets used?

The simplest change of all is to add the striping pattern
offset field to the nfsv4_1_file_layout4 data type. Given the
amount of work the editors have to do in the next two weeks in order
to allows to issue WG last call this year that is the least disruptive.

Since it is a simple change, that is what I'll do now. If we have
a rough consensus to solve the problem a different way, then that
can be done, but likely not before 2008.