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

[Benny Halevy <[e-mail]>]

-------- Original Message --------
Subject: Re: [nfsv4] New version of     sparse
draft(draft-hildebrand-nfsv4-read-sparse-01.txt)
Date: Mon, 04 Oct 2010 14:07:30 -0400
From: Benny Halevy <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail],
[e-mail],  [e-mail]

On 2010-10-04 13:29, [e-mail] wrote:
>
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]]
>> On Behalf Of Benny Halevy
>> Sent: Monday, October 04, 2010 7:55 AM
>> To: Thomas Haynes
>> Cc: J. Bruce Fields; Erasani, Pranoop; [e-mail]
>> Subject: 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
>> <[e-mail]> 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
>
> I like this approach as well.  However it does present some complexity.  The value returned to the client has to be interpreted by the client, using the layout, to determine whether data may exist on another DS in the _possible_ hole.  Dense vs. sparse striping must also be taken into account.  The DS can only return the next byte offset in the stripe file where data exists (having no knowledge of stripe boundaries or dense/sparse striping).
>

Correct. The client has to do the reverse mapping, given the layout and
striping pattern.

Benny

>   -Dan
>
>>
>>>
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/nfsv4
>>>
>> _______________________________________________
>> nfsv4 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nfsv4
>>
>>
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4