A number of users have reported that under certain conditions using the overlay filesystem, copy_file_range() can unexpectedly create a 0-byte file. [0] This bug can cause significant problems because applications that copy files expect the target file to match the source immediately after the copy. After upgrading from Linux 5.4 to Linux 5.10, our Docker-based CI tests started failing due to this bug, since Ruby's IO.copy_stream uses this system call. We have worked around the problem by touching the target file before using it, but this shouldn't be necessary. Other projects, such as Rust, have added similar workarounds. [1] As discussed in the linux-fsdevel mailing list [2], the bug appears to be present in Linux 5.6 to 5.10, but not in Linux 5.11. We should be able to cherry-pick the following upstream patches to fix this. Could you cherry-pick them to 5.10.x stable? I've confirmed that these patches, applied from top to bottom to that branch, pass the reproduction test [3]: 82a763e61e2b601309d696d4fa514c77d64ee1be 9b91b6b019fda817eb52f728eb9c79b3579760bc The diffstat: fs/overlayfs/file.c | 59 +++++++++++++++++++++++++++++++---------------------------- 1 file changed, 31 insertions(+), 28 deletions(-) Note that these patches do not pick cleanly into 5.6.x - 5.9.x stable. [0] https://github.com/docker/for-linux/issues/1015 [1] https://github.com/rust-lang/rust/blob/342db70ae4ecc3cd17e4fa6497f0a8d9534ccfeb/library/std/src/sys/unix/kernel_copy.rs#L565-L569 [2] https://marc.info/?l=linux-fsdevel&m=163847383311699&w=2 [3] https://github.com/docker/for-linux/issues/1015#issuecomment-841915668