Re: [nfsv4] Genart last call review of draft-ietf-nfsv4-flex-files-15

[Thomas Haynes <[e-mail]>]

> On Dec 22, 2017, at 11:47 AM, Christer Holmberg <[e-mail]> wrote:
> 
> Hi Thomas,
> 
> ...
> 
>>> Q1:
>>> 
>>> The Abstract says:
>>> 
>>>  "The flexible file layout type is defined in this
>>>  document as an extension to pNFS which allows the use of storage
>>>  devices in a fashion such that they require only a quite limited
>>>  degree of interaction with the metadata server, using already
>>>  existing protocols."
>>> 
>>> …and the Introduction says:
>>> 
>>>  "There are different layout types for different storage
>>>  systems and methods of arranging data on storage devices.  This
>>>  document defines the flexible file layout type used with file-based
>>>  data servers that are accessed using the Network File System (NFS)
>>>  protocols: NFSv3 [RFC1813], NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], and
>>>  NFSv4.2 [RFC7862].”
>>> 
>>> But, there is no text about the existing file layout type, and how 
>>> this file layout types will improve things.
>> 
>> It does not have to improve things, it is just a different layout type.
> 
> But, shouldn't there be any description about the difference between the existing file layout type? Is there some specific scenario in mind? Is there some characteristic(s) specific to the flexible file layout type?
> 
> I assume there was *SOME* reason for defining the flexible file layout type - other than just defining a new layout type for the sake of it :)


The old type did not allow you to use NFSv3 to access the storage devices.

Which is covered here:

   This
   document defines the flexible file layout type used with file-based
   data servers that are accessed using the Network File System (NFS)
   protocols: NFSv3 [RFC1813], NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], and
   NFSv4.2 [RFC7862].

DISCLAIMER: I am too close to this document and after RFC 7530 and RFC 7862, I tend to be terse.

In general, a new layout type is created to access the storage devices via a
different protocol than provided by existing layout types. See RFC 8154 and
draft-hellwig-nfsv4-rdma-layout-00.

I’ll add some text to make apparent the desire is to access non-NFSv4 storage devices.





> 
>>> The Abstract mentions impacts on the interactions with the metadata server, but there is no text about that 
>>> in the Introduction.
>> 
>> There is, but perhaps the relationship needs to be explained.
>> 
>> The entire second paragraph is about the interactions with the metadata server.
> 
> If that is specific to the flexible file layout type, I think it should be explicitly stated.
> 
>>> I think a few sentences in the Introduction, describing the high-level 
>>> advantages and changes that the flexible file layout type brings, 
>>> would be good.
>>> 
>>> Also, the Abstract mentions client mirroring, but there is nothing 
>>> about that in the Introduction.
>>> 
>> 
>> Both of these were on purpose - I wanted to introduce the terms in Section 1.1 before using them.
> 
> That is fine.
> 
>> I’ll add the high-level summary, including client side mirroring.
> 
> Thanks!
> 
> 
>>> Q2:
>>> 
>>> Is section 2 specific to the flexible file layout type, or is it about 
>>> pNFS in general? I think it would good to have a sentence describing 
>>> the scope of the section.
>> 
>> It starts out general for all pNFS and covered more specifically in [pNFSLayouts].
>> 
>> And having said that, I disagree with it immediately.
> 
> Disagree with what? My suggestion to have a sentence describing the scope?

No, hah! My statement of "It starts out general for all pNFS and covered more specifically in [pNFSLayouts].”



> 
>> I can point the reader to [pNFSLayouts] and paint the scope as to how FlexFiles will address this issue.
> 
> Thanks!
> 
> Regards,
> 
> Christer
>