On Mon, Jul 18, 2022 at 5:01 AM Paul Thompson <paul.a.thompson@xxxxxxxxxxxx> wrote: > > Something that worked in 5.18.9 no longer does in 5.18.1[01] and 5.19-rc6. > > Using the example code in the man page for copy_file_range: > > # ./copy-file-range testfile-on-ext4 /path-to-another-ext4/testfile (or symlink thereto) > > Works in 5.18.9, fails with: > > # copy_file_range: Invalid cross-device link > > And produces garbage file at destination on newer (5.18.10+) kernels. > > This breaks eg. qbittorrent (moving a distro image across ext4 > filesystems, or following such a symlink) So potentially other real world > applications. I do not know if the reason for the commit overrides this > breakage, but it caused me a bit of a headache. > Hi Paul, I apologize for the headache this change has caused you. FWIW, Arvidn has already fixed the problem in libtorrent 2.0.7 release yesterday following a report by Mat [1]. The story here is that cross-fs copy_file_range() was not allowed pre kernel v5.3. When we started allowing it in v5.3, we did not and we could not test all possible combinations of src and dst fs, so it took a few years, but regression reports started to surface [2]. We decided to try and revert the behavior to pre kernel v5.3 to fix those regressions. The first attempt was around v5.12 release, but sadly, the patch got ignored and it wasn't before v5.19-rc5 that we managed to get the patch merged. In the meanwhile, libtorrent 2.0.0 was released with code that assumes that cross-fs copy_file_range() failure is a fatal error. This was fixed is 2.0.7 released yesterday and I hope this fix will be packaged soon for distros. There is no easy way to find if other userspace tools have made the same assumptions except for getting regression reports like yours. It is encouraging to me that I got two regression reports from you and Mat shortly after the kernel patch was merged, which suggests that if there are other userspace tools out there making the same assumption, we will hear about them in the near future. If we find out that is it too late to revert to pre v5.3 behavior, then there are a few other options that were discussed on [2], but none of them are pretty and there was no consensus on either solution, so I'd rather wait a bit to see if other workloads rely on cross-fs copy_file_range() from any src fs to any dst fs, before taking further action. Thanks, Amir. [1] https://github.com/qbittorrent/qBittorrent/issues/17352 [2] https://lore.kernel.org/linux-fsdevel/20210212044405.4120619-1-drinkcat@xxxxxxxxxxxx/
