Re: [nfsv4] New Version Notification for draft-bhalevy-nfs-obj-00.txt

On 2012-10-08 22:46, Haynes, Tom wrote:
> Hi Adam!
> 
> 
> 
> On Oct 8, 2012, at 2:57 PM, Adam C. Emerson <aemerson@linuxbox.com> wrote:
> 
>> Salutations,
>>
>> At Sun, 7 Oct 2012 20:37:11 -0400 (EDT), Matt W. Benjamin wrote:
>>> ----- "Tom Haynes" <Tom.Haynes@netapp.com> wrote:
>> [snip]
>>>
>>>> By the way, fine with such a proposal does not mean I think it would
>>>> be wise to implement. These
>>>> NFS devices presented here have to be very dumb because of the lack of
>>>> a control protocol between
>>>> them and the MDS. I don't see how they handle locks, stateids, and any
>>>> state in general. Once we
>>>> throw in sparse files in NFSv4.2, I don't see how they would be
>>>> communicated.
>> [snip]
>>
>> As Matt mentioned, the draft as written certainly supports dumb NFS
>> servers with no knowledge that they are participating as data servers,
>> but does not seem to outlaw a control protocol.  As to sparse files,
>> the description of READ_PLUS in the NFSv4.2 draft says:
>>
>>   If the data to be returned is comprised entirely of zeros, then the
>>   server may elect to return that data as a hole.  The server
>>   differentiates this to the client by setting di_allocated to TRUE
>>   in this case.  Note that in such a scenario, the server is not
>>   required to determine the full extent of the "hole" - it does not
>>   need to determine where the zeros start and end.
>>
>> I read this to mean that even a relatively dumb data server that knows
>> it contains a sparse region can return this fact to the client without
>> having to worry about the content of other data servers, if the server
>> were to issue a layout with major version 4 and minor version 2.
> 
> 
> Lets pick something that needs more communication - say Labeled NFS.
> How does the MDS communicate the label to the DSes?
> 
> When it recalls the delegation, how is fencing supported against
> client ops?
> 
> 
>>
>> We believe this layout type could be productively expanded with a
>> transport type for NFSv4.1 that indicated it should be treated as a
>> data server, including the communication of the stateid.  This would
>> combine the improved data server semantics with the more capable
>> description of the object layout, giving the best of both worlds.
> 
> 
> I just don't see it right now in the draft as it is - not arguing against
> it, just have concerns it is not being explored well enough.
> 
> One thing that bugs me about the draft is in figuring out when READ
> means an OSD READ, a NFS READ, etc. This lack of clarity makes
> it difficult to follow the flow of interaction with the MDS, DS as an OSD,
> and DS as an NFS Server.
> 

I'll try to clarify that in the next version.

Benny

>>
>> We also believe that this layout type should be expanded with a
>> packing flag to allow it to support sparse as well as dense packing,
>> as sparse packing is superior for systems using irregular striping
>> patterns.
> 
> 
> Bring that up with Benny.
> 
> 
>>
>> Respectfully yours,
>>
>> Adam C. Emerson                                  <aemerson@linuxbox.com>
> 
> And I hope I was respectful back!
> Tom
> _______________________________________________
> nfsv4 mailing list
> nfsv4@ietf.org
> https://www.ietf.org/mailman/listinfo/nfsv4
> 