|
|
|
|
|
|
by chlorion
934 days ago
|
|
|
It's worth noting that copy_file_range is used by a lot of things. Most programming languages "copy_file" functions use copy_file_range, everything from Rust to Emacs Lisp! The only language I can think of that doesn't use copy_file_range when copying files is Python. On Gentoo, the portage package manager is written in Python but has some "native extensions", one of these extensions is copying files with copy_file_range, which is used when merging images to the root filesystem from my understanding. Also GNU coreutils "cp" command uses it by default in recent releases, I'm not sure which release specifically introduced this change. There are other things required to trigger the bug that are a lot less common though. |
|
|
Yes, but the trigger feature, block cloning, only landed in the latest 2.2 release. If you immediately hopped on 2.2, and used a system with lots copy_file_range and FICLONE use, yes, you may have a problem (like, as you note, on Gentoo, where this problem surfaced).
Most people were just hopping on the bandwagon. My distro ships 2.1.5, so I have a 6 month wait until this feature lands, so I was just building copy_file_range support into my ZFS apps, right before news of this bug hit.[0]
> There are other things required to trigger the bug that are a lot less common though.
Exactly. My guess is the incidence of this will exceedingly rare for the common user/small NAS user/etc. I've run a corruption detector[1], and what I've found mostly indicates false positives. Fingers crossed, but, so far, no actual positive matches on a system with probably a little less than 1 million files.
[0]: https://github.com/kimono-koans/httm [1]: https://gist.github.com/kimono-koans/2696a8c8eac0a6babf7b2d9...