[PATCH 0/3] Use copy_file_range while performing copy

[Goldwyn Rodrigues]

This patch set uses copy_file_range() instead of legacy read() and
write() calls to the filesystem to copy a file. The advantage is we save
on memory allocations and frequent system calls to the kernel.

As the man page suggests, this performs a copy_file_range() using
SEEK_HOLE and SEEK_DATA to find the holes. It copies the data using
copy_file_range() and writes zeros if sparse_mode is set to NEVER.
It falls back to legacy copy for sparse_mode ALWAYS because userspace is
the best judge for identifying and creating holes.

While I carved out legacy copy, I added fallocate(st_blocks) to the
calls which should make the writes a bit more faster because the
filesystem would not compute for allocating space every write() call.

"make check" passes all tests on btrfs.

Pádraig, this should address most of your concerns of using
copy_file_range() you brought up in the previous discussion [1]
I am fine with delaying this until the next major release, if there are
no further objections. A filesystem may still choose to
perform a reflink underneath, but I suppose there is not much we can do
with that since filesystems can even perform de-duping later with
utilities such as dedupe or even inline dedeuping.

[1] http://lists.gnu.org/archive/html/coreutils/2018-05/msg00072.html

-- 
Goldwyn