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

From: "Barry Leiba" <[email-masked]>
Date: Wed, 20 Jan 2016 15:53:14 -0800

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

-- 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

-- 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?  Why does
this say "regions of"?

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?  Can some file systems write a
region of zeroes without "knowing" that they have created a hole?  Does
this distinction matter here?

-- 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".

   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?

   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."

-- 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.

-- 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.

---

From: David Noveck <[email-masked]>
Date: Thu, 21 Jan 2016 10:46:24 -0500

Regarding:

I'd like to propose the following alternate text:

This document describes the NFSv4.2 protocol as a set of extensions to
the specification for NFSv4.1. That specification remains current and
forms the basis for the additions defined herein.  In addition, the
specfication
for NFSv4.0 remains current as well.

It is necessary to implement all the REQUIRED features of NFSv4.1 before
adding NFSv4.2 features to the implementation.

On Wed, Jan 20, 2016 at 6:53 PM, Barry Leiba <[email-masked]>
wrote:

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Barry Leiba <[email-masked]>
Date: Thu, 21 Jan 2016 12:02:45 -0500

Nice, and an improvement over my version.  Thanks!

Barry

---

From: Tom Haynes <[email-masked]>
Date: Fri, 22 Jan 2016 16:19:29 -0800

> On Jan 21, 2016, at 7:46 AM, David Noveck <[email-masked]> wrote:
> 
> Regarding:
> 
> forms the basis for the additions defined herein.  In addition, the specfication

Taken

> 
> 
> On Wed, Jan 20, 2016 at 6:53 PM, Barry Leiba <[email-masked] <mailto:[email-masked]>> wrote:
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-minorversion2/ <https://datatracker.ietf.org/doc/draft-ietf-nfsv4-minorversion2/>
> 
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>
>

---

From: Tom Haynes <[email-masked]>
Date: Mon, 25 Jan 2016 11:59:54 -0800

Hi Barry,

Thanks for the comments!

Responses inline:

> On Jan 20, 2016, at 3:53 PM, Barry Leiba <[email-masked]> wrote:
> 

As noted in the reply to Dave Noveck, I took his counter-proposal.

>   through earlier versions of NFS, and to offer them remotely.

I’m fine with that change.

> 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.

> 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

The way it matters is that we know we do not have to transfer the data across the wire.

> hole is present or not”.

I’m fine with not appearing so stiff. :-)

Taken.

> you might just want to say "Returning actual data blocks corresponding to

Yes

> 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.

> 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.

> fact, not a protocol option.

Agreed.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 25 Jan 2016 15:03:18 -0500

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

Barry