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

[Rick Macklem <[e-mail]>]

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.

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.

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