On 2016/05/11 10:40, Qu Wenruo wrote:
Chris Mason wrote on 2016/05/10 20:37 -0400:
On Tue, May 10, 2016 at 03:19:52PM +0800, Qu Wenruo wrote:
Hi, Chris, Josef and David,
As merge window for v4.7 is coming, it would be good to hear your ideas
about the inband dedupe.
We are addressing the ENOSPC problem which Josef pointed out, and we believe
the final fix patch would come out at the beginning of the merge
window.(Next week)
If it's fine, would you please consider to merge the in-memory backend
patchset for v4.7 as an experimental feature?
Most of the patch won't be changed from v10 patchset, only ENOSPC fix will
be updated, and ioctl patchset will introduce a new Kconfig option of "btrfs
experimental features" for inband dedupe.
(With explain about unstable ioctl/on-disk format for experimental features)
If you are all OK to merge inband dedupe in-memory backend, I'll prepare the
new v11 patchset for this merge.
We have to balance the part where we really want the features to come
in, and we want to lower the load on you to continue porting them. But,
I really do agree that we need strong test suites included with every
major feature like this.
-chris
That's fine.
We're running all generic and btrfs test case with dedupe enabled,
> by modifying xfstest to call "btrfs dedeup enable"
just after mount, to ensure dedupe won't corrupt any existing test case.
How about writing the xfstests patch that we can run
the above tests without modifying xfstests by hand?
Then it becomes easy for everyone to test dedupe.
Thanks,
Satoru
And we are also enriching our dedupe test cases to reduce the stability concern
on the new feature.
BTW, does it mean inband dedup won't catch v4.7 merge window and no need to
submit a v11 patchset for this merge window?
Thanks,
Qu
--
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
--
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
