While testing a custom tool using this reflink module, I observed incomplete copies when using the fallback copy_file_range mechanism: Larger files were always truncated to 2,147,479,552 bytes. This limit shows up in other places on Linux, such as described in write(2): "On Linux, write() (and similar system calls) will transfer at most 0x7ffff000 (2,147,479,552) bytes, returning the number of bytes actually transferred. (This is true on both 32-bit and 64-bit systems.)" In this specific instance I was copying data on an NFSv3.1 volume but this issue is likely to also appear in other places.
The current copyFileRange function assumes the entire copy can succeed in one call, but the function should loop until the expected number of bytes have been copied.
While testing a custom tool using this reflink module, I observed incomplete copies when using the fallback copy_file_range mechanism: Larger files were always truncated to 2,147,479,552 bytes. This limit shows up in other places on Linux, such as described in write(2): "On Linux, write() (and similar system calls) will transfer at most 0x7ffff000 (2,147,479,552) bytes, returning the number of bytes actually transferred. (This is true on both 32-bit and 64-bit systems.)" In this specific instance I was copying data on an NFSv3.1 volume but this issue is likely to also appear in other places.
The current copyFileRange function assumes the entire copy can succeed in one call, but the function should loop until the expected number of bytes have been copied.