Re: 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]> 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]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

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