All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Eryu Guan <eguan@redhat.com>
Cc: fstests@vger.kernel.org
Subject: Re: [PATCH] generic/038: speed up file creation
Date: Mon, 10 Aug 2015 09:20:46 +1000	[thread overview]
Message-ID: <20150809232046.GH16638@dastard> (raw)
In-Reply-To: <20150809104558.GM17933@dhcp-13-216.nay.redhat.com>

On Sun, Aug 09, 2015 at 06:45:58PM +0800, Eryu Guan wrote:
> On Fri, Aug 07, 2015 at 08:21:27AM +1000, Dave Chinner wrote:
> > Seeing as you can reproduce the problem, I encourage you to work out
> > what the minimum number of files need to reproduce the problem is,
> > and update the test to use that so that it runs even faster...
> 
> I found that 50000 files per thread is good enough for me to reproduce
> the fs corruption, sometimes WARNINGs. With 20000 or 30000 files per
> thread, only 20% to 33% runs could hit some problems. So this is what
> I'm testing (comments are not updated)
> 
> [root@dhcp-66-87-213 xfstests]# git diff
> diff --git a/tests/generic/038 b/tests/generic/038
> index 3c94a3b..7564c87 100755
> --- a/tests/generic/038
> +++ b/tests/generic/038
> @@ -108,6 +108,7 @@ trim_loop()
>  #
>  # reating 400,000 files sequentially is really slow, so speed it up a bit
>  # by doing it concurrently with 4 threads in 4 separate directories.
> +nr_files=$((50000 * LOAD_FACTOR))
>  create_files()
>  {
>         local prefix=$1
> @@ -115,7 +116,7 @@ create_files()
>         for ((n = 0; n < 4; n++)); do
>                 mkdir $SCRATCH_MNT/$n
>                 (
> -               for ((i = 1; i <= 100000; i++)); do
> +               for ((i = 1; i <= $nr_files; i++)); do
>                         $XFS_IO_PROG -f -c "pwrite -S 0xaa 0 3900" \
>                                 $SCRATCH_MNT/$n/"${prefix}_$i" &> /dev/null
>                         if [ $? -ne 0 ]; then
> 
> Would you like a follow up patch from me or you can just make this one a v2?

Ok, I'll fold that into my original patch, update the comment and
the commit message with:

[Eryu Guan: reduced number of files to minimum needed to reproduce
 btrfs problem reliably, added $LOAD_FACTOR scaling for longer
 running.]

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

      reply	other threads:[~2015-08-09 23:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-06  0:27 [PATCH] generic/038: speed up file creation Dave Chinner
2015-08-06 14:17 ` Eryu Guan
2015-08-06 22:21   ` Dave Chinner
2015-08-07  8:09     ` Filipe David Manana
2015-08-07 23:22       ` Dave Chinner
2015-08-09 10:45     ` Eryu Guan
2015-08-09 23:20       ` Dave Chinner [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=20150809232046.GH16638@dastard \
    --to=david@fromorbit.com \
    --cc=eguan@redhat.com \
    --cc=fstests@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.