Subject: [nfsv4] fixed up version of testcfr.c

From: Rick Macklem <[email-masked]>
Date: Tue, 15 Oct 2019 23:33:23 +0000

Attached is a version of testcfr.c that seems to work for a Linux
NFSv4.2 client when compiled with "-DDOSYNC". DOSYNC adds
some fsync(2) calls plus close()/open() after doing the copy_file_range().
{ I'm not sure that a client app should need to do these things, but that's
  up to the Linux community. }

At least for Fedora30, a copy_file_range() where the in_fd and out_fd are
the same file and the byte range overlaps returns success, but the data
seems bogus. However, this occurs when run on a local FS as well, so
I don't think it's a Linux NFSv4.2 client bug.

Good luck with it, if you try it, rick

---

From: Rick Macklem <[email-masked]>
Date: Wed, 16 Oct 2019 05:58:23 +0000

Trond Myklebust wrote:
>Hi Rick
>
>On Tue, 2019-10-15 at 23:33 +0000, Rick Macklem wrote:
>The above would be a server bug. According to RFC7862 section 15.2.3:
>
>   SAVED_FH and CURRENT_FH must be different files.  If SAVED_FH and
>   CURRENT_FH refer to the same file, the operation MUST fail with
>   NFS4ERR_INVAL.
If the client attempted a Copy for this case, then, yes.
But if you look at a packet trace, the client doesn't attempt a Copy, but tries
to do this with a Write.

rick

--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
[email-masked]