linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
To: Qu Wenruo <quwenruo@cn.fujitsu.com>, Chris Mason <clm@fb.com>,
	Josef Bacik <jbacik@fb.com>, David Sterba <dsterba@suse.com>,
	btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: About in-band dedupe for v4.7
Date: Wed, 11 May 2016 11:26:19 +0900	[thread overview]
Message-ID: <5732984B.1000809@jp.fujitsu.com> (raw)
In-Reply-To: <a8fdf4f2-4b3c-7c17-1709-55ae61888f94@cn.fujitsu.com>

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2016-05-11  2:26 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-10  7:19 About in-band dedupe for v4.7 Qu Wenruo
2016-05-10 22:11 ` Mark Fasheh
2016-05-11  1:03   ` Qu Wenruo
2016-05-11  2:52     ` Mark Fasheh
2016-05-11  9:14       ` Qu Wenruo
2016-05-11 17:36       ` David Sterba
2016-05-12 20:54         ` Mark Fasheh
2016-05-13  7:14           ` Duncan
2016-05-13 12:14           ` Austin S. Hemmelgarn
2016-05-13 14:25             ` Qu Wenruo
2016-05-13 16:37             ` Zygo Blaxell
2016-05-16 15:26           ` David Sterba
2016-05-13  6:01         ` Zygo Blaxell
2016-05-11 16:56   ` David Sterba
2016-05-13  3:13   ` Wang Shilong
2016-05-13  3:44     ` Qu Wenruo
2016-05-13  6:21       ` Zygo Blaxell
2016-05-16 16:40     ` David Sterba
2016-05-11  0:37 ` Chris Mason
2016-05-11  1:40   ` Qu Wenruo
2016-05-11  2:26     ` Satoru Takeuchi [this message]
2016-05-11  4:22     ` Mark Fasheh
2016-05-11 16:39 ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5732984B.1000809@jp.fujitsu.com \
    --to=takeuchi_satoru@jp.fujitsu.com \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=jbacik@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo@cn.fujitsu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).