Re: proposed change to RFC-7862 to align Seek semantics with the extant client implementation
Rick Macklem <[email protected]>
| Newsgroups | gmane.ietf.nfsv4 |
|---|---|
| Message-ID | <YTBPR01MB2845939A854D0C41816AB11CDD6B0@YTBPR01MB2845.CANPRD01.PROD.OUTLOOK.COM> |
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 _______________________________________________ nfsv4 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nfsv4