https://bugs.kde.org/show_bug.cgi?id=458001
Méven <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED Latest Commit|https://invent.kde.org/fram |https://invent.kde.org/fram |eworks/kio/commit/fa8edc709 |eworks/kio/-/commit/7d9df74 |9820d72179b29ccd15535b5398c |0872357bb314d23f81ad5f150d6 |5952 |a69768 --- Comment #14 from Méven <[email protected]> --- Git commit 7d9df740872357bb314d23f81ad5f150d6a69768 by Méven Car. Committed on 30/10/2026 at 09:44. Pushed by meven into branch 'master'. file_unix_copy: align copy_file_range calls on 8 MiB Before this change, the copy started with a 512 KiB chunk and doubled it, so every call after the first started on an odd multiple of 512 KiB. ZFS clones only whole records, 1 MiB by default, and copies the data of any other range. This also holds for a server-side copy over NFS or SMB to a ZFS server. A copy within a ZFS dataset then took the space twice. copy_file_range() calls now start with 8 MiB and end on a multiple of the largest power of two in the chunk, at least 8 MiB, except at the end of the file. A clone takes milliseconds, so a call slower than the latency target moves the data, such as between two NFS mounts without a server-side copy. The chunk can then shrink to 512 KiB again, as before. The sendfile() path between two filesystems keeps the 512 KiB start, as nothing can be cloned there. M +27 -5 src/kioworkers/file/file_unix_copy.cpp https://invent.kde.org/frameworks/kio/-/commit/7d9df740872357bb314d23f81ad5f150d6a69768 -- You are receiving this mail because: You are watching all bug changes.
