linux: work around copy_file_range() cephfs bug #3123
Conversation
Pre-4.20 kernels have a bug where CephFS uses the RADOS copy-from command when it shouldn't. Fall back to a regular file copy. Fixes: libuv#3117 Refs: torvalds/linux@6f9718f
src/unix/fs.c
Outdated
| static unsigned uv__kernel_version(void) { | ||
| struct utsname u; | ||
| unsigned major; | ||
| unsigned minor; | ||
| unsigned patch; | ||
|
|
||
| if (-1 == uname(&u)) | ||
| return 0; | ||
|
|
||
| if (3 != sscanf(u.release, "%u.%u.%u", &major, &minor, &patch)) | ||
| return 0; | ||
|
|
||
| return major * 65536 + minor * 256 + patch; | ||
| } |
There was a problem hiding this comment.
Would it make sense caching the kernel version in a static variable?
There was a problem hiding this comment.
I don't think it can hurt - updated.
| @@ -926,6 +974,9 @@ static ssize_t uv__fs_sendfile(uv_fs_t* req) { | |||
| /* ENOSYS - it will never work */ | |||
| errno = 0; | |||
| copy_file_range_support = 0; | |||
| } else if (r == -1 && errno == EACCES && uv__is_buggy_cephfs(in_fd)) { | |||
| errno = 0; | |||
| copy_file_range_support = 0; | |||
There was a problem hiding this comment.
As a small aside: these should use uv__store_relaxed() rather than assign directly. I'll do that in a follow-up PR.
There was a problem hiding this comment.
I opened a PR to use those functions in #3124. Will update it again once this gets landed. :)
|
@bnoordhuis Another issue has been reported at nodejs/node#37763 that seems to involve the same bug except, this time it's not cephfs. |
|
Might be useful to be aware of the various copy_file_range bugs described in https://lwn.net/Articles/846403/ and comments about them (however, that is about as far as my knowledge goes on this, so I may not be of any further help). |
|
@RaisinTen What file system was the reporter using? |
They don't seem to mention it in the nodejs bug report, but when I was testing to report my own experience with cephfs, I tested with NFS to see if I could reproduce the bug on it and I could, so I think NFS has a similar issue with the |
cc @joeheyming |
I'm aware of the issues with procfs and I'm not too surprised nfs is affected. Probably the best course of action is to switch to an allowlist of known-good file systems: btrfs, cephfs, ext4, jfs, xfs - any others? |
Pre-4.20 kernels have a bug where CephFS uses the RADOS copy-from command when it shouldn't. Fall back to a regular file copy. Fixes: libuv#3117 Refs: torvalds/linux@6f9718f PR-URL: libuv#3123 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
|
Landed in 9737baf. Thanks! |
Pre-4.20 kernels have a bug where CephFS uses the RADOS copy-from command when it shouldn't. Fall back to a regular file copy. Fixes: libuv#3117 Refs: torvalds/linux@6f9718f PR-URL: libuv#3123 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Santiago Gimeno <santiago.gimeno@gmail.com>
Pre-4.20 kernels have a bug where CephFS uses the RADOS copy-from
command when it shouldn't. Fall back to a regular file copy.
Fixes: #3117
Refs: torvalds/linux@6f9718f
cc @kakaroto - can you confirm that it fixes the issue you're seeing?