Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Rick Macklem <rmacklem@uoguelph.ca>
To:     Tom Talpey <tom@talpey.com>,
        "J. Bruce Fields" <bfields@fieldses.org>
CC:     "Kornievskaia, Olga" <Olga.Kornievskaia@netapp.com>,
        "linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>,
        "nfsv4@ietf.org" <nfsv4@ietf.org>
Subject: Re: NFSv4.2 server replies to Copy with length == 0
Thread-Topic: NFSv4.2 server replies to Copy with length == 0
Thread-Index: AQHVg8vy6XBow5lmmE6IMuCp/6tuzqdcytI+gACiuwCAAEGxgIAACqQAgABZSj+AAOK5gIAABIMAgAAFGTM=
Date:   Thu, 17 Oct 2019 16:20:17 +0000
Message-ID: <YQBPR0101MB16525B93EA77EC9F6937FFFADD6D0@YQBPR0101MB1652.CANPRD01.PROD.OUTLOOK.COM>
References: <YQBPR0101MB1652856488503987CEB17738DD920@YQBPR0101MB1652.CANPRD01.PROD.OUTLOOK.COM>
 <YQBPR0101MB1652DEF8AD7A6169D44D47C6DD920@YQBPR0101MB1652.CANPRD01.PROD.OUTLOOK.COM>
 <20191016155838.GA17543@fieldses.org>
 <31E6043B-090D-4E37-B66F-A45AC0CFC970@netapp.com>
 <20191016203150.GC17543@fieldses.org>
 <YQBPR0101MB16524CABD71AACBD2D9DC651DD6D0@YQBPR0101MB1652.CANPRD01.PROD.OUTLOOK.COM>
 <20191017152253.GG32141@fieldses.org>,<6f98f9ab-bf81-3a4a-64e7-2abef60e20d4@talpey.com>
In-Reply-To: <6f98f9ab-bf81-3a4a-64e7-2abef60e20d4@talpey.com>
Accept-Language: en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: uoguelph.ca does not designate
 permitted sender hosts)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8BIT
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0339d5e8-338a-465e-f585-08d7531de624
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2019 16:20:17.6063
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ooQMjlyceQmsZFxZCCWKmx8wh0dXDEpUxA5agrcrFSNcg0AcSPZoiOOk6zXdMqLX+nquYt1UbvlR2UqdjrWFfQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB1844
Sender: linux-nfs-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org

Tom Talpey wrote:
>On 10/17/2019 11:22 AM, J. Bruce Fields wrote:
>> On Thu, Oct 17, 2019 at 02:16:36AM +0000, Rick Macklem wrote:
>>> I have now found two cases where the Linux NFSv4.2 server does not
>>> conform to RFC-7862. One is as above and the other is a reply to Seek
>>> of NFS4ERR_NXIO when the sa_offset argument == file_size (instead of
>>> replying NFS_OK along with sr_eof == true).
>>
>> Huh.  Looks like that's documented behavior of Linux's seek.  (See the
>> ERRORS section of the lseek(2) man page.)  Looks like Solaris also
>> returns -ENXIO in this case:
>>
>>       https://docs.oracle.com/cd/E26502_01/html/E29032/lseek-2.html
>>
>> And freebsd too:
>>
>>       https://www.freebsd.org/cgi/man.cgi?query=lseek&sektion=2
>>
>> I wonder where that spec language came from?
>
>Those manpages look like ENXIO comes back only on sparse files. Perhaps
>this is boilerplate from v4.0 before this kind of thing was common.
As far as I know, a non-sparse file (no holes) behaves the same as a file with
holes in it. (I'm not sure if the POSIX draft is clear for the case where the
file system does not support holes, but I think most implementations handle
that the same way as a file with no holes on a file system that supports holes.)

>This should at least be discussed on nfsv4@ietf.org...
I think there needs to be a discussion on how to best deal with cases where
implementations have shipped to users with these glitches in them.

I think it might be better to document them, so that client coders can
implement work arounds (I am doing so for the three cases I've found)
instead of the server being patched to change its behaviour, causing
potentially more interoperability issues.
(That's why I re-posted this to nfsv4@ietf.org.)

>> Our NFS server could translate an -ENXIO return into 0 and sr_eof ==
>> true easily enough, assuming -ENXIO is really only ever returned in that
>> case.
>>
>> I haven't tested, but from a quick check of the Linux client code I
>> think that would require a matching fix on the client side to translate
>> sr_eof == 0 *back* to ENXIO.
>>
>> I don't know if it's worth it.
>
>What Bad Thing would happen for the difference?
Well, for a POSIX draft style client, the only effect is that a client may be
broken (not handle the sr_eof == true reply correctly) without the
implementors knowing that, since they tested against the Linux server.
(I believe this is the current status of the Linux client.)

For a server implementor (I get to wear both hats;-), the server can only
generate one reply or the other. I've implemented both with a tunable
that can be used to flip between them. I default to the NFS4ERR_NXIO
reply, since that is what the Linux client expects.

As for the Copy issues, the client can easily handle them, but the client
coder needs to know about them.
At this time the FreeBSD server code only implements what is in the RFC.
This seems sufficient for the testing I've done sofar.
The case that I think will break would be Linux code that does a
copy_file_range(infd, NULL, outfd, NULL, INT_MAX, 0) to copy an entire
file. I'll test this case to-day, but I'm think it will just get a NFS4ERR_INVAL
reply from the FreeBSD server.
(I can make this work for the Linux client, but it will take another "cheat"
 enabled via a tunable.)
--> Part of the confusion here comes from the fact that the Linux syscall
       semantics for copy_file_range() has changed. (I also where the
       copy_file_range(2) hat for FreeBSD, so I've got some work to do there, too.)

In summary, I think that, since Linux has been shipping this for some time,
documenting workarounds is a practical approach.

rick