Subject: Re: [nfsv4] File Layout change proposal

From: "Anatoly Pinchuk" <[email-masked]>
Date: Fri, 7 Dec 2007 20:05:20 -0800

>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
 
nfls_off is the logical file offset of the file segment represented with
nfsv4_1_file_layout_segment4. That includes striping pattern, data file
handles and other information. We can change name nfls_off to something
more informative.
 
>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?
 
Because in case of dense packing we translate client file offset into
data file one. The translation algorithm guarantees that client's data
is not overwritten. The details of the translation are described in my
previous posting.
 
>What if the number of elements in nflda_multipath_ds_list equals  
>nflda_stripe_indices? Which filehandle gets used?
 
Order is important. "nflda_multipath_ds_list" case is applicable since
is listed first.
 
>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.
 
The simplicity has two dimensions. First is the amount of work to change
the current draft. Second one is the simplicity and correctness of the
protocol structures. The changes I proposed are small and well known;
therefore, it should not take too much time to incorporate them into the
protocol. As for the second dimension, there is big difference between
two approaches. I have already described downsides of returning array of
layout4 as result of LAYOUTGET. Addition of offset into
nfsv4_1_file_layout4 type along with keeping the array adds unnecessary
complication and duplication. Another problem of having unnatural
dependency between number of the data file handles and packing is not
addressed at all.
 
- Anatoly
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4