On 6/19/20 3:11 PM, David Sterba wrote:
If there wasn't some insurmountable reason
why duperemove can't be merged with btrfs-progs, then it would have
happened already, so there must be a reason why this can't ever happen
(which might be as simple as neither maintainer wants to merge).
I'm not against adding the functionality to btrfs-progs, but merging
whole duperemove feature set might not happen due to additional
dependencies. This would need to be evaluated, but I'm not aware of any
other technical reasons.
I don't remember exactly why duperemove started as a separate project
instead of a subcommand or progs, but we can revisit that.
Even tough I don't think that this was the reason at the time, now the ioctl FIDEDUPERANGE (aka BTRFS_IOC_FILE_EXTENT_SAME) is "filesystem agnostic". So I think that does make sense a tool more generic than btrfs(-progs).
What I mean is: because this is not a BTRFS specific ioctl anymore, why we should have a BTRFS specific implementation ?
From a technical point of view: dupremover could take advantage of the btrfs csum. So the question could be : is it better to add the capability to use the BTRFS csum to duperemover or to add the code of dupremover to BTRFS ?
From an user point of view, I think that the former makes sense.
BR
G.Baroncelli
--
gpg @keyserver.linux.it: Goffredo Baroncelli <kreijackATinwind.it>
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
