linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: Eryu Guan <eguan@redhat.com>
Cc: fstests@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Al Viro <viro@ZenIV.linux.org.uk>, Jan Kara <jack@suse.cz>,
	tytso@mit.edu, axboe@kernel.dk, mawilcox@microsoft.com,
	ross.zwisler@linux.intel.com, corbet@lwn.net,
	dhowells@redhat.com, linux-ext4@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-block@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [xfstests PATCH v3 5/5] btrfs: allow it to use $SCRATCH_LOGDEV
Date: Thu, 08 Jun 2017 08:48:07 -0400	[thread overview]
Message-ID: <1496926087.12725.1.camel@redhat.com> (raw)
In-Reply-To: <20170606091930.GR19952@eguan.usersys.redhat.com>

On Tue, 2017-06-06 at 17:19 +0800, Eryu Guan wrote:
> On Wed, May 31, 2017 at 09:08:20AM -0400, Jeff Layton wrote:
> > With btrfs, we can't really put the log on a separate device. What we
> > can do however is mirror the metadata across two devices and make the
> > data striped across all devices. When we turn on dmerror then the
> > metadata can fall back to using the other mirror while the data errors
> > out.
> > 
> > Note that the current incarnation of btrfs has a fixed 64k stripe
> > width. If that ever changes or becomes settable, we may need to adjust
> > the amount of data that the test program writes.
> > 
> > Signed-off-by: Jeff Layton <jlayton@redhat.com>
> > ---
> >  common/rc | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/common/rc b/common/rc
> > index 83765aacfb06..078270451b53 100644
> > --- a/common/rc
> > +++ b/common/rc
> > @@ -830,6 +830,8 @@ _scratch_mkfs()
> >  		;;
> >  	btrfs)
> >  		mkfs_cmd="$MKFS_BTRFS_PROG"
> > +		[ "$USE_EXTERNAL" = yes -a ! -z "$SCRATCH_LOGDEV" ] && \
> > +			mkfs_cmd="$mkfs_cmd -d raid0 -m raid1 $SCRATCH_LOGDEV"
> 
> I don't think this is the correct way to do it. If btrfs doesn't support
> external log device, then this test doesn't fit btrfs, or we need other
> ways to test btrfs.
> 
> One of the problems of this hack is that raid1 requires all devices are
> in the same size, we have a _require_scratch_dev_pool_equal_size() rule
> to check on it, but this hack doesn't do the proper check and test fails
> if SCRATCH_LOGDEV is smaller or bigger in size.
> 
> If btrfs "-d raid0 -m raid1" is capable to do this writeback error test,
> perhaps you can write a new btrfs test and mkfs with "-d raid0 -m raid1"
> explicitly. e.g.
> 
> ...
> _require_scratch_dev_pool 2
> _require_scratch_dev_pool_equal_size
> ...
> _scratch_mkfs "-d raid0 -m raid1"
> ...
> 
> Thanks,
> Eryu


Yeah, that's probably the right way to do this. It looks like btrfs also
has $SCRATCH_DEV_POOL, and we can probably base it on that. I'll look at
reworking it.

-- 
Jeff Layton <jlayton@redhat.com>

      reply	other threads:[~2017-06-08 12:48 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-31 13:08 [xfstests PATCH v3 0/5] add a test for reporting writeback errors across all fds on fsync Jeff Layton
2017-05-31 13:08 ` [xfstests PATCH v3 1/5] generic: add a writeback error handling test Jeff Layton
2017-05-31 18:59   ` Eduardo Valentin
2017-05-31 20:02     ` Jeff Layton
2017-06-06  8:58   ` Eryu Guan
2017-06-06 10:15     ` Jeff Layton
2017-06-06 12:23       ` Eryu Guan
2017-06-06 17:17         ` Darrick J. Wong
2017-06-06 20:12           ` Jeff Layton
2017-06-06 22:07             ` Darrick J. Wong
2017-05-31 13:08 ` [xfstests PATCH v3 2/5] ext4: allow ext4 to use $SCRATCH_LOGDEV Jeff Layton
2017-06-06  9:01   ` Eryu Guan
2017-05-31 13:08 ` [xfstests PATCH v3 3/5] generic: test writeback error handling on dmerror devices Jeff Layton
2017-06-06  9:05   ` Eryu Guan
2017-05-31 13:08 ` [xfstests PATCH v3 4/5] ext3: allow it to put journal on a separate device when doing scratch_mkfs Jeff Layton
2017-06-06  9:06   ` Eryu Guan
2017-05-31 13:08 ` [xfstests PATCH v3 5/5] btrfs: allow it to use $SCRATCH_LOGDEV Jeff Layton
2017-06-06  9:19   ` Eryu Guan
2017-06-08 12:48     ` Jeff Layton [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=1496926087.12725.1.camel@redhat.com \
    --to=jlayton@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=corbet@lwn.net \
    --cc=dhowells@redhat.com \
    --cc=eguan@redhat.com \
    --cc=fstests@vger.kernel.org \
    --cc=jack@suse.cz \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mawilcox@microsoft.com \
    --cc=ross.zwisler@linux.intel.com \
    --cc=tytso@mit.edu \
    --cc=viro@ZenIV.linux.org.uk \
    /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).