pkg/fileutils: add LinkOrCopy() #2251
Conversation
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: giuseppe, Luap99 The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
There was a problem hiding this comment.
Thanks! I agree c/storage is the right place for this.
I wonder whether we want the “…OrCopy” part; it seems somewhat attractive to me to have drivers/copy.CopyRegularToFile call this new function. (And there’s… friction: that function needs to explicitly implement doCopyWithFileRange only because it relies on pools.Copy, which defeats the equivalent of doCopyWithFileRange inside the standard library.)
I think we can start with this …OrCopy function for now, and we can always add a reflink-only function later — I’m pointing this out in case others think differently.
Add a function to copy via reflink if possible or fall back to the normal io.Copy(). c/image uses this function internally[1] however I like to export this and use it in podman and I think this package here in c/storage is the most logical location for it. Note compared to the c/image version I am calling unix.IoctlFileClone() directly instead of the raw syscall function. [1] https://github.com/containers/image/tree/main/internal/reflink Signed-off-by: Paul Holzinger <pholzing@redhat.com>
|
On modern Linux BTW Rust automatically uses that by default via specialization for its std::io::copy |
Add a function to copy via reflink if possible or fall back to the normal io.Copy().
c/image uses this function internally[1] however I like to export this and use it in podman and I think this package here in c/storage is the most logical location for it. Note compared to the c/image version I am calling unix.IoctlFileClone() directly instead of the raw syscall function.
[1] https://github.com/containers/image/tree/main/internal/reflink