All of lore.kernel.org
 help / color / mirror / Atom feed
From: Filipe Manana <fdmanana@kernel.org>
To: Dave Chinner <david@fromorbit.com>
Cc: fstests@vger.kernel.org,
	"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
	Filipe Manana <fdmanana@suse.com>
Subject: Re: [PATCH] fstests: btrfs, test for send with clone operations
Date: Tue, 9 Feb 2016 22:17:26 +0000	[thread overview]
Message-ID: <CAL3q7H4g9NdAktgQdVAF4t-5r=9uqTZhLF=EHw2Go4SsC_d+UA@mail.gmail.com> (raw)
In-Reply-To: <20160204212134.GE31407@dastard>

On Thu, Feb 4, 2016 at 9:21 PM, Dave Chinner <david@fromorbit.com> wrote:
> On Thu, Feb 04, 2016 at 12:11:28AM +0000, fdmanana@kernel.org wrote:
>> From: Filipe Manana <fdmanana@suse.com>
>>
>> Test that an incremental send operation which issues clone operations
>> works for files that have a full path containing more than one parent
>> directory component.
>>
>> This used to fail before the following patch for the linux kernel:
>>
>>   "[PATCH] Btrfs: send, fix extent buffer tree lock assertion failure"
>>
>> Signed-off-by: Filipe Manana <fdmanana@suse.com>
>
> Looks ok, I've pulled it in. Something to think about:
>
>> +# Create a bunch of small and empty files, this is just to make sure our
>> +# subvolume's btree gets more than 1 leaf, a condition necessary to trigger a
>> +# past bug (1000 files is enough even for a leaf/node size of 64K, the largest
>> +# possible size).
>> +for ((i = 1; i <= 1000; i++)); do
>> +     echo -n > $SCRATCH_MNT/a/b/c/z_$i
>> +done
>
> We already do have a generic function for doing this called
> _populate_fs(), it's just not optimised for speed with large numbers
> of files being created.
>
> i.e. The above is simple a single directory tree with a single level
> with 1000 files of size 0:
>
>         _populate_fs() -d 1 -n 1 -f 1000 -s 0 -r $SCRATCH_MNT/a/b/
>
> Can you look into optimising _populate_fs() to use multiple threads
> (say up to 4 by default) and "echo -n" to create files, and then
> convert all our open coded "create lots of files" loops in tests to
> use it?

Sure, I'll take a look at it when I get some spare time.
Thanks Dave.

>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> david@fromorbit.com

      reply	other threads:[~2016-02-09 22:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-04  0:11 [PATCH] fstests: btrfs, test for send with clone operations fdmanana
2016-02-04 21:21 ` Dave Chinner
2016-02-09 22:17   ` Filipe Manana [this message]

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='CAL3q7H4g9NdAktgQdVAF4t-5r=9uqTZhLF=EHw2Go4SsC_d+UA@mail.gmail.com' \
    --to=fdmanana@kernel.org \
    --cc=david@fromorbit.com \
    --cc=fdmanana@suse.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-btrfs@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.