closes #980 implement reflink (copy-on-write) file copying with fallb… #1121
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds copy-on-write file cloning to improve storage efficiency on supported filesystems.
New
reflink.rs
module with Linux FICLONE ioctl support.Updated copy operation to try reflink first, fall back to standard copy.
Works transparently on Btrfs, XFS, Bcachefs - falls back on others, or non-linux OS.
I think checking filesystem type is unreliable because:
Btrfs supports reflink but only on same filesystem
XFS supports reflink but has version requirements
ZFS supports reflink but via different mechanism
ext4 doesn't support reflink at all
In my opinion the cleanest approach is what we're doing:
Attempt the ioctl directly
Let the kernel tell us if it works or not
Clean up and fallback on failure
This is actually the standard approach used by tools like cp --reflink=auto - they don't pre-check, they just attempt and handle the failure gracefully.
tested on BTRFS and EXT4