Re: [nfsv4] Barry Leiba's No Objection on draft-ietf-nfsv4-minorversion2-40: (with COMMENT)

[Barry Leiba <[e-mail]>]

Thanks for the response, Tom.  All good here, and I appreciate your
addressing my comments!

Barry


On Mon, Jan 25, 2016 at 2:59 PM, Tom Haynes
<[e-mail]> wrote:
> Hi Barry,
>
> Thanks for the comments!
>
> Responses inline:
>
>> On Jan 20, 2016, at 3:53 PM, Barry Leiba <[e-mail]> wrote:
>>
>> Barry Leiba has entered the following ballot position for
>> draft-ietf-nfsv4-minorversion2-40: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-minorversion2/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> I appear to be in the minority here, in that I *did* understand this
>> document's place relative to 4.0, and 4.1.  Still, I agree that
>> clarifying that is really important, and I'll suggest a specific
>> clarification in Section 1.1):
>>
>> OLD
>>   This document describes the NFSv4.2 protocol.  With respect to
>>   NFSv4.0 and NFSv4.1, this document does not:
>> NEW
>>   This document describes the NFSv4.2 protocol as extensions to
>>   the specifications of NFSv4.0 and NFSv4.1. Those specifications
>>   remain current and form the basis for the additions defined
>>   herein.  It is necessary to implement those before adding
>>   NFSv4.2 to the implementation.
>>
>>   With respect to NFSv4.0 and NFSv4.1, this document does not:
>> END
>
> As noted in the reply to Dave Noveck, I took his counter-proposal.
>
>
>
>>
>> -- Section 1.2 --
>>
>>   A major goal of the design of NFSv4.2 is to take common local file
>>   system features and offer them remotely.
>>
>> This sounds like it means to be a change in goals relative to 4.0 and
>> 4.1.  I think it would fit better to say it this way, and would add to
>> the clarification above:
>>
>> NEW
>>   A major goal of the enhancements provided in NFSv4.2 is to take
>>   common local file system features that have not been available
>>   through earlier versions of NFS, and to offer them remotely.
>> END
>
> I’m fine with that change.
>
>
>>
>> -- Section 6.1 --
>>
>>   Hole:  A byte range within a Sparse file that contains regions of all
>>      zeroes.  A hole might or might not have space allocated or
>>      reserved to it.
>>
>> I'm wondering about the "regions of" here: If I have a byte range that
>> contains two regions of all zeroes and something that's not all zeroes in
>> between those two regions, I do not have a (single) hole, do I?
>
>
> No, you have two.
>
>
>>  Why does
>> this say "regions of”?
>
> When I read it as you’ve laid it out, I agree with you.
>
> I thought of taking off the plural, but I like this better:
>
>   Hole:  A byte range within a Sparse file that contains all
>      zeroes.  A hole might or might not have space allocated or
>      reserved to it.
>
>
>
>>
>> And a question: Is there any disctinction between a byte-range within a
>> sparse file that happens to contain all zeroes... and one that is
>> recorded in metadata as being all zeroes?
>
> As far as the local filesystem, yes.
>
> As far as transferring across the wire, no.
>
>
>>  Can some file systems write a
>> region of zeroes without "knowing" that they have created a hole?  Does
>> this distinction matter here?
>
>
> The way it matters is that we know we do not have to transfer the data across the wire.
>
>
>>
>> -- Section 6.2.1 --
>>
>>   Note that as the client has no a priori
>>   knowledge of whether a hole is present or not
>>
>> (No need to respond to this; take it or leave it as you please.)  I have
>> a general preference for avoiding Latin terms, as they're not properly
>> understood by everyone.  In this case, too, "a priori" has a connotation
>> that goes beyond the literal Latin translation.  I think it'd be better
>> to word this as "Because the client does not know in advance whether a
>> hole is present or not”.
>
> I’m fine with not appearing so stiff. :-)
>
> Taken.
>
>>
>>   READ_PLUS extends the response with a new arm representing holes to
>>   avoid returning data for portions of the file which are initialized
>>   to zero and may or may not contain a backing store.  Returning data
>>   blocks of uninitialized data wastes computational and network
>>   resources, thus reducing performance.
>>
>> It wouldn't be "uninitialized" data, would it?  It'd be zeroes.  I think
>> you might just want to say "Returning actual data blocks corresponding to
>> holes", yes?
>
>
> Yes
>
>
>>
>>   By contrast, if a READ_PLUS occurs in the middle of a hole,
>>   the server can send back a range which starts before the offset and
>>   extends past the range.
>>
>> I'm not sure how a range can extend past itself ("a range which ...
>> extends past the range").  I think you just want to say "a range
>> representing the hole.”
>
>
> How about this?
>
>   By contrast, if a READ_PLUS occurs in the middle of a hole,
>   the server can send back a range which starts before the offset and
>   extends past the requested length.
>
>
>>
>> -- Section 6.2.2 --
>>
>>   DEALLOCATE can be used to hole punch, which allows the client to
>>   avoid the transfer of a repetitive pattern of zeros across the
>>   network.
>>
>> This is the first time you've mentioned DEALLOCATE where I think I
>> understand that it is a way of doing a WRITE wherein the client sends the
>> representation of a hole to the server, rather than actually doing a
>> WRITE.  (I had previously thought it was used to tell the server to undo
>> an ALLOCATE, but it now seems that they are related things, but are not
>> duals.)
>>
>> You might want to be more clear about this here, especially if what I say
>> in the previous paragraph is wrong.
>
> No, it is another form of WRITE and it is why we did not provide WRITE_PLUS.
>
>
> Does this work better for you?
>
>
>         The client can use the DEALLOCATE operation on a range
>         of a file as a hole punch, which allows the
>         client to avoid the transfer of a repetitive pattern of zeros
>         across the network. This hole punch is a result of the
>         unreserved space returning all zeros until overwritten.
>
>
>
>>
>> -- Section 7 --
>>
>>   Lesser space MAY be
>>   consumed for backups after block deallocation.
>>
>> I don't think this is a proper 2119 MAY; it sounds like a statement of
>> fact, not a protocol option.
>>
>>
>
> Agreed.
>