Does it involve network to copy a file within a NFS share?

Question

I am assuming the following ways to copy a file with in a NFS share:

Process 1:

• The client requests for the data to be copied from NFS share (if cache is not there) and the chunks of data are asynchronously copied to memory of the NFS client which then asynchronously send it to the NFS filer again to copy to new location.
• The NFS filer receives the chunks of data asynchronously in the memory and writes it to the new location.
• In this process, though there is network involved while reading and also writing, due to asynchronous read & write, the latency for one overall read-write operation will be same as latency for read-write operation of overall data.

Hence, reading from local hard disk and writing to NFS is almost same as reading from NFS and write to NFS.

In the first step, if cache is already there, the reading can be very quick.

Process 2:

• The client send request to initiate the data copy operation to NFS server, along with the location from where it has to read and where it has to write (seems it is not).
• The server does the rest, read-write operations using it's own memory.

Hence, no network involved. And hence, can have better performance (unless there is no latency at the network end) But it is likely not the way.

Please correct me at every point, if I am wrong.

Also, does the memory involves at every operation, I mean when it sends data across network, the data is first sent to memory (data buffer) from disk and then from memory (data buffer) to data buffer (on the other side of the network), but not from data buffer to disk on the other side of the network right?

Answer 1

NFSv4.2 does have a offload-copy operation which can do server-to-server copy without proxying data trough the client. Modern linux kernels (> 3.13?) supports that. I don't know about other servers.

UPDATE

By linux kernel 4.7 server side copy is not supported by linux servers https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/fs/nfsd/nfs4xdr.c?id=refs/tags/v4.7-rc6#n1797

UPDATE 2

With kernel version 5.6 the server side copy is added to the NFSD implementation

https://lkml.org/lkml/2020/2/7/687

Answer 2

The "copy a file" operation is not a basic file-system operation such as read, write, open, close, and similar operations. See this page for a good explanation of the operations a filesystem has to support.

And that's all file systems - whether it's ext4, btrfs, or nfsv4.

Note that there's no way to know why a process opens file A, opens file B, reads from file A, then writes to file B. So, in general there's no way to "short-circuit" and optimize the copying of a file so that the data doesn't have to cross the network twice in the case of both file A and file B being on NFS file systems, even if they're shared from the same NFS server.

Many operating systems do provide system calls such as sendfile(), which do efficiently copy data by removing the need to copy the data to and from user space, and in theory that could be done at the file system level for copying files, but even then there would have to be restrictions similar to that on the rename() operation - such a hypothetical copyfile() operation would likely have to be restricted to short-circuiting only those copies within a single file system. To do otherwise would make a complex mess - what to do if file A and file B are on the same NFS server, a client wants to copy from one to the other, but file A is on an ext4 file system and file B is on another XFS file system?