Re: proposed change to RFC-7862 to align Seek semantics with the extant client implementation

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

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.

I suggest that the following lines (on page #91 in RFC-7862):
   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.

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.

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

rick

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

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

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.

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.

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.

   For the purposes of dealing with SEEK, all files are considered to 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: David Noveck <[email protected]>
Sent: Thursday, October 24, 2019 2:01 PM
To: Rick Macklem
Cc: [email protected]
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 protected]<mailto:[email protected]>> wrote:
A slight update of the Rationale...

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.

I understand that that is so.


However, RFC-7862 does not seem to clearly state that this is the correct
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.
...
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'm not sure what confusion you are referring to.

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.

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
area at the end of file.

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.

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.

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

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.

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.

   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.
_______________________________________________
nfsv4 mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/nfsv4

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

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