Message ID | 20181106064122.6154-1-lufq.fnst@cn.fujitsu.com (mailing list archive) |
---|---|
Headers | show |
Series | Btrfs In-band De-duplication | expand |
De-duplication must also let use cases to enable de-duplication on per subvolume level, using the subvolume properties. Similar to compression and future-encryption. Thanks, Anand
On Tue, Nov 06, 2018 at 02:41:09PM +0800, Lu Fengqi wrote: > This patchset can be fetched from github: > https://github.com/littleroad/linux.git dedupe_latest > > Now the new base is v4.20-rc1. Before anybody spends more time with this patchset: this is a big feature and quite intrusive to several btrfs subsystems. Currently it's on hold as it requires finishing the design phase, it's still only the in-memory backend and before we claim in-band dedupe, the persistent hash tree needs to be at least drafted or prototyped. At this point there are several features that are in a more complete state so they get preferred when it comes to merging. I would have to look up what was agreed long time ago as merging plan, but at this point this series would require a lot of work.
On Tue, Nov 13, 2018 at 02:45:45PM +0100, David Sterba wrote: >On Tue, Nov 06, 2018 at 02:41:09PM +0800, Lu Fengqi wrote: >> This patchset can be fetched from github: >> https://github.com/littleroad/linux.git dedupe_latest >> >> Now the new base is v4.20-rc1. > >Before anybody spends more time with this patchset: this is a big >feature and quite intrusive to several btrfs subsystems. Currently it's >on hold as it requires finishing the design phase, it's still only the >in-memory backend and before we claim in-band dedupe, the persistent >hash tree needs to be at least drafted or prototyped. Thanks for your explanation. However, I'm not sure why we need to draft a prototype of the persistent hash tree first when we are talking about the memory backend.