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
