Subject: [nfsv4] proposed change to RFC-7862 to align Seek semantics with the extant client implementation

From: Rick Macklem <[email-masked]>
Date: Wed, 23 Oct 2019 22:56:01 +0000

Rationale:
At this time, the main and possibly only NFSv4.2 client that has shipped to
users expects a reply to Seek for the case of:
sa_offset: file_size
sa_what: NFS4_CONTENT_DATA

to be NFS4ERR_NXIO.

However, RFC-7862 does not seem to clearly state that this is the correct
reply to a Seek with the above arguments.
I believe the confusion stems from the fact that there is a virtual hole at
the end of the file, but not a virtual data area at the end of file.

I propose that the following change be made to RFC-7862 in order to
to clarify the use of the virtual hole and the correct server reply for the
above case, so that future NFSv4.2 server implementations can interoperate
with the extant Linux client implementation that is shipping to users.

I suggest that the following lines (on page #91 in RFC-7862):
   From the given sa_offset, find the next data_content4 of type sa_what
   in the file.  If the server cannot find a corresponding sa_what, then
   the status will still be NFS4_OK, but sr_eof would be TRUE.  If the
   server can find the sa_what, then the sr_offset is the start of that
   content.  If the sa_offset is beyond the end of the file, then SEEK
   MUST return NFS4ERR_NXIO.

   All files MUST have a virtual hole at the end of the file.  That is,

be replaced with:
   From the given sa_offset, find the next data_content4 of type sa_what
   in the file.
   If the server can find the sa_what, then the sr_offset is the start of that
   content.  If the sa_offset is beyond the end of the file, or for
   NFS4_CONTENT_DATA at the end of file, then SEEK
   MUST return NFS4ERR_NXIO.

   All files MUST have a virtual hole at the end of the file.
   Therefore, for NFS4_CONTENT_HOLE, if the sa_offset is at the end of the
   file, this virtual hole will be found and a status of NFS4_OK with
   sr_eof set to TRUE will be returned.

rick

---

From: Rick Macklem <[email-masked]>
Date: Wed, 23 Oct 2019 23:25:10 +0000

A slight update of the Rationale...

Rationale:

to be NFS4ERR_NXIO.

However, RFC-7862 does not seem to clearly state that this is the correct
reply to a Seek with the above arguments.
I believe the confusion stems from the fact that there is a virtual hole at
the end of the file, but not a virtual data area at the end of file.
This sentence from page #91
   If the server cannot find a corresponding sa_what, then
   the status will still be NFS4_OK, but sr_eof would be TRUE.
makes sense for the case of NFS4_CONTENT_HOLE, since a virtual hole
exists at the end of the file. However, it makes less sense to return
the above for the case of NFS4_CONTENT_DATA, since there is no virtual data
area at the end of file.

be replaced with:

rick

---

From: David Noveck <[email-masked]>
Date: Thu, 24 Oct 2019 14:01:44 -0400

> sa_what: NFS4_CONTENT_DATA

I understand that that is so.

> reply to a Seek with the above arguments..

In fact, it states that a different response is the correct one,.   I don't
think there
is much point discussing the clarity (or not) of that text but there is no
uncertainty
about what is is correct according to RFC7862.  As a result, the working
group is
being asked to change the spec.   This can be done without disruption since
there
are no clients that expect different behavior.
.

> the end of the file, but not a virtual data area at the end of file.

I'm not sure what confusion you are referring to.

> exists at the end of the file.

It doesn't apply in that case.   Since there is a virtual hole at the end
of the fiile,
one would *always *be able to find a corresponding sa_what.

However, it makes less sense to return
> the above for the case of NFS4_CONTENT_DATA, since there is no virtual data

In which case there is no corresponding sa_what and the above statement "
the status
will still be NFS4_OK, but sr_eof would be TRUE" applies.   That  make
sense as written
although you (and probably the author of the Linux client support for this)
might have
chosen something dIfferent.

> This would provide better interoperation but don't think there is any
clarification
provided by this.

>    MUST return NFS4ERR_NXIO.

This is a change rather than a clarification.

>    All files MUST have a virtual hole at the end of the file.

The way this is stated  impies more than is probably intended.  For
example, if you
do a read beyond EOF, you do not get zeroes from the virtual hole.

Would prefer something like:

    For the purposes of dealing with SEEK, all files are considred to have
a virttual hole at
    the end of the file.

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

---

From: Rick Macklem <[email-masked]>
Date: Fri, 25 Oct 2019 01:05:26 +0000

Ok, so how about this (using some of your words)?

Rationale:

to be NFS4ERR_NXIO.

I propose that the following modification be made to RFC-7862 in order to
to change the defined server reply for the above case, so that future NFSv4.2
server implementations can interoperate with the extant Linux client implementation that is shipping to users.
This can be done without disruption since there
are no clients that expect the behaviour described in RFC-7862 at this time.

be replaced with:

   For the purposes of dealing with SEEK, all files are considered to have a
    virtual hole at the end of the file.

rick

________________________________________
From: David Noveck <[email-masked]>
Sent: Thursday, October 24, 2019 2:01 PM
To: Rick Macklem
Cc: [email-masked]
Subject: Re: [nfsv4] proposed change to RFC-7862 to align Seek semantics with the extant client implementation

On Wed, Oct 23, 2019 at 7:25 PM Rick Macklem <[email-masked]<mailto:[email-masked]>> wrote:
A slight update of the Rationale...

Rationale:

to be NFS4ERR_NXIO.

In fact, it states that a different response is the correct one,.   I don't think there
is much point discussing the clarity (or not) of that text but there is no uncertainty
about what is is correct according to RFC7862.  As a result, the working group is
being asked to change the spec.   This can be done without disruption since there
are no clients that expect different behavior.
.
I believe the confusion stems from the fact that there is a virtual hole at
the end of the file, but not a virtual data area at the end of file.

It doesn't apply in that case.   Since there is a virtual hole at the end of the fiile,
one would always be able to find a corresponding sa_what.

In which case there is no corresponding sa_what and the above statement " the status
will still be NFS4_OK, but sr_eof would be TRUE" applies.   That  make sense as written
although you (and probably the author of the Linux client support for this) might have
chosen something dIfferent.

This would provide better interoperation but don't think there is any clarification
provided by this.

be replaced with:

The way this is stated  impies more than is probably intended.  For example, if you
do a read beyond EOF, you do not get zeroes from the virtual hole.

    For the purposes of dealing with SEEK, all files are considred to have a virttual hole at
    the end of the file.

[email-masked]<mailto:[email-masked]>

---

From: Rick Macklem <[email-masked]>
Date: Fri, 25 Oct 2019 14:27:46 +0000

Here is a rewording of the change that is closer to the original and handles
the case where the file has a hole ending at the size of the file. The Linux
server returns NFS4ERR_NXIO for a NFS4_CONTENT_DATA Seek with an
sa_offset within that hole, as well.

Rationale:

to be NFS4ERR_NXIO.

be replaced with:
   If the server cannot find a corresponding sa_what, then
   the status will be NFS4ERR_NXIO. If the
   server can find the sa_what, then the sr_offset is the start of that
   content.  If the sa_offset is beyond the end of the file, then SEEK
   returns the status NFS4ERR_NXIO.

rick

________________________________________
From: nfsv4 <[email-masked]> on behalf of Rick Macklem <[email-masked]>
Sent: Thursday, October 24, 2019 9:05 PM
To: David Noveck
Cc: [email-masked]
Subject: Re: [nfsv4] proposed change to RFC-7862 to align Seek semantics with the extant client implementation

Rationale:

to be NFS4ERR_NXIO.

be replaced with:

rick

Rationale:

to be NFS4ERR_NXIO.

..

be replaced with: