Starting with 6.10, I'm seeing `copy_file_range()`, with source and
destination being on the same FUSE filesystem[1], failing with EIO in
some cases. The (low-level libfuse3) userspace filesystem does not
implement `copy_file_range`, so the kernel falls back to the generic
implementation. The userspace filesystem receives read requests and
replies with the `FUSE_BUF_SPLICE_MOVE` flag.
I'm not sure what exactly triggers the issue but it may depend on the
file size, among other things. I can reproduce it fairly reliably
attempting to copy files that are exactly 65536 bytes in size.
6.9 works fine but I see the issue in 6.10, 6.10.3 and also in current
master ee9a43b7cfe2.
413e8f014c8b848e4ce939156f210df59fbd1c24 is the first bad commit
commit 413e8f014c8b848e4ce939156f210df59fbd1c24 (HEAD)
Author: Matthew Wilcox (Oracle) <willy@xxxxxxxxxxxxx>
Date: Sat Apr 20 03:50:06 2024 +0100
fuse: Convert fuse_readpages_end() to use folio_end_read()
Nobody checks the error flag on fuse folios, so stop setting it.
Optimise the (optional) setting of the uptodate flag and clearing
of the lock flag by using folio_end_read().
Signed-off-by: Matthew Wilcox (Oracle) <willy@xxxxxxxxxxxxx>
Signed-off-by: Miklos Szeredi <mszeredi@xxxxxxxxxx>
I've confirmed the bisection by reverting this commit on top of 6.10.3,
which resolves the issue.
#regzbot introduced: 413e8f014c8b
Cheers,
Jürg
[1] https://gitlab.com/BuildGrid/buildbox/buildbox/-/tree/master/fuse
