Re: [nfsv4] New version of sparse draft(draft-hildebrand-nfsv4-read-sparse-01.txt)

On Sun, Oct 3, 2010 at 10:54 PM, Thomas Haynes <thomas@netapp.com> wrote:
> The harder case is for a non-clustered pNFS community, i.e., one
> where the MDS and DSes need a control protocol to talk. Let's
> assume that is the case here.
>
> A hole is created when a WRITE happens at a DS that is not
> contiguous with the previous (if any) WRITE.
>
> If a DS is supposed to return the range until the next non-zero
> data, then it will need to contact every other DS or perhaps
> the MDS.
>
> If the MDS is supposed to honor a GET_SPARSE_BLOCK_MAP
> type of request from the client, then either each DS would have
> to send hole entries to the MDS or the MDS would have to
> probe each one.
>
> What if instead of a DS returning information about other DSes,
> it simply returns information about what it knows? I.e., my next
> data is at address X.

I think that this is much cleaner from the protocol perspective.
The DS is essentially serving NFSv4.1 so its READ result applies
to the current filehandle which represents the slice stored
on it, not the logical file striped across multiple DSs.

Benny

>
> Consider a file with a width of 32k. The first write it gets is at 1M
> and then it gets 5 other contiguous writes. The next data is at
> 2M and it gets 4 other contiguous writes. The DS can't assume
> that any other DS has zeros in the first 1M. Worst case, all other
> N-1 DSes do have data there.
>
> In that scenario, N-1 DSes will return 32k on the first read and
> 1 DS will return a hole for it only until 1M. The client will then
> only send N-1 READs until it it gets to the 1M mark.
>
>
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
>