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>
prev parent 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).