On Mon, Aug 31, 2015 at 09:13:29AM +0800, Qu Wenruo wrote: > > That's the wrong interface to use for such actions. > > > But IMHO, deduplication is much like compression, we only need to > execution extra hook to handle data at run_delalloc_range().
It is, but the filesystem-wide compression already shows its limitations. Eg. it's not possible to set the compression on a per-subvolume (or at least per-subvolume-mount [*]) basis, it's not possible to select the compression method for a given file or directory. Next, changing the status of dedup via remount is quite a heavy operation. Remount has to sync the whole filesystem, while this is not strictly necessary for changes in the dedup parameters. The ioctl, if designed well, can be ready for future enhancements and we can fine-tune the dedup engine in ways that we do not forsee right now. I really don't want to see the mount options grow that way. > And even better than compression, inline dedup won't even cause any > format change. > So I'd prefer to use mount option other than introduce a new ioctl > interface. Yeah, no change in the format makes it just a matter of selecting the right interface to manage dedup. (I don't remember if there were other points that I wrote back then when Liu Bo sent his in-band dedup patches and wanted to use the mount options as well.) [*] I do have a POC for that, mostly working and will submit at least for RFC -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html