Because Debian coreutils 9.1-1 "cp" silently falls back to copy_file_range() after FICLONE reports EIO, "cp" can transfer incorrect bytes. Linux syscalls having a file descriptor parameter report EIO after a fault in the underlying device. The affected file is not recoverable in the general case, but syscall outcomes after the EIO don't reflect that. For example, consider FICLONE returning EIO for a fault during source file writeback. The kernel will mark "clean" the affected page cache entries and clear the EIO state. If the page cache evicts those pages, their file offsets revert to the last written-back values if any, else zeros. If userspace issues a syscall that bypasses the page cache, like copy_file_range() or another FICLONE, that syscall clones the last written-back state or zeroes. See https://lore.kernel.org/linux-xfs/20221108172436.ga3613...@rfd.leadboat.com for a "cp" and "cat" test script, background, and discussion.
I recommend instead reporting the EIO and terminating when FICLONE or copy_file_range() fails with EIO. One could argue that ENOSPC also warrants termination, since no fallback reduces space usage. For other errno values, fallback to the next transfer strategy, like today. An alternative would be to fallback from FICLONE to copy_file_range() only after known-appropriate errors EBADF, EINVAL, EOPNOTSUPP, ETXTBSY, and EXDEV. That alternative wins if future FICLONE reports an additional termination-deserving errno value. Since just EIO needs termination today, I bet new errno values are more likely than not to deserve fallback. What do you think? Thanks, nm
