On Mon, Nov 7, 2016 at 6:40 PM, Christoph Anton Mitterer <calestyo@xxxxxxxxxxxx> wrote: > On Mon, 2016-11-07 at 15:02 +0100, David Sterba wrote: >> I think adding a whole-file dedup mode to duperemove would be better >> (from user's POV) than writing a whole new tool > > What would IMO be really good from a user's POV was, if one of the > tools, deemed to be the "best", would be added to the btrfs-progs and > simply become "the official" one. Yeah there's two problems, one being that the extent-same ioctl (and duperemove) is cross-file system now so I. The other one James touches on, which is that there's a non trivial amount of complexity in duperemove so shoving it in btrfs progs just means we're going to have parallel development streams solving some different problems. That's not to say that every dedupe tool has to be complex - we have xfs_io to run the ioctl and I don't think it'd be a bad idea if btrfs-progs had a simple interface to it too. --Mark -- "When the going gets weird, the weird turn pro." Hunter S. Thompson -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
