From: Eryu Guan <eguan@redhat.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org
Subject: Re: [PATCH v5 0/9] xfstests: online scrub/repair support
Date: Thu, 26 Jan 2017 13:08:38 +0800 [thread overview]
Message-ID: <20170126050838.GN1859@eguan.usersys.redhat.com> (raw)
In-Reply-To: <148498621936.17109.4249711513404036449.stgit@birch.djwong.org>
On Sat, Jan 21, 2017 at 12:10:19AM -0800, Darrick J. Wong wrote:
> Hi all,
>
> This is the fifth revision of a patchset that adds to XFS userland tools
> support for online metadata scrubbing and repair.
>
> The new patches in this series do three things: first, they expand the
> filesystem populate commands inside xfstests to be able to create all
> types of XFS metadata. Second, they create a bunch of xfs_db wrapper
> functions to iterate all fields present in a given metadata object and
> fuzz them in various ways. Finally, for each metadata object type there
> is a separate test that iteratively fuzzes all fields of that object and
> runs it through the mount/scrub/repair loop to see what happens.
>
> If you're going to start using this mess, you probably ought to just
> pull from my github trees for kernel[1], xfsprogs[2], and xfstests[3].
Are your github trees synced with kernel.org trees? Seems so, and I did
my tests with your kernel.org trees.
> The kernel patches in the git trees should apply to 4.10-rc4; xfsprogs
> patches to for-next; and xfstest to master.
>
> The patches have survived all auto group xfstests both with scrub-only
> mode and also a special debugging mode to xfs_scrub that forces it to
> rebuild the metadata structures even if they're not damaged.
I have trouble finishing running all the tests so far, the tests need
long time to run and in some tests xfs_repair or xfs_scrub are just
spinning there, sometimes I can kill them to make test continue,
sometimes I can't (e.g. xfs/1312, I tried to kill the xfs_scrub process,
but it became <defunc>).
And in most tests I have run, I see such failures:
+scrub didn't fail with length = ones.
+scrub didn't fail with length = firstbit.
+scrub didn't fail with length = middlebit.
+scrub didn't fail with length = lastbit.
....
Not sure if that's expected?
I also hit xfs_scrub and xfs_repair double free bug in xfs/1312 (perhaps
that's why I can't kill it).
OTOH, all these failures/issues seem like kernel or userspace bug, I
went through all the patches and new tests and I didn't find anything
wrong obviously. So I think it's fine to merge them in this week's
update. Unless you have a second thought?
Thanks,
Eryu
next prev parent reply other threads:[~2017-01-26 5:08 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-21 8:10 [PATCH v5 0/9] xfstests: online scrub/repair support Darrick J. Wong
2017-01-21 8:10 ` [PATCH 1/9] populate: create all types of XFS metadata Darrick J. Wong
2017-01-21 8:10 ` [PATCH 2/9] populate: add _require_populate_commands to check for tools Darrick J. Wong
2017-01-21 8:10 ` [PATCH 3/9] populate: optionally fill the filesystem when populating fs Darrick J. Wong
2017-01-21 8:10 ` [PATCH 4/9] populate: fix some silly errors when modifying a fs while fuzzing Darrick J. Wong
2017-01-21 8:10 ` [PATCH 5/9] common/fuzzy: move fuzzing helper functions here Darrick J. Wong
2017-01-27 8:12 ` Eryu Guan
2017-01-27 9:24 ` Darrick J. Wong
2017-01-21 8:10 ` [PATCH 6/9] populate: cache scratch metadata images Darrick J. Wong
2017-01-21 8:11 ` [PATCH 7/9] populate: discover XFS structure fields and fuzz verbs, and use them to fuzz fields Darrick J. Wong
2017-01-21 8:11 ` [PATCH 8/9] common/populate: create attrs in different namespaces Darrick J. Wong
2017-01-21 8:11 ` [PATCH 9/9] xfs: fuzz every field of every structure Darrick J. Wong
2017-01-21 19:38 ` [PATCH v5 0/9] xfstests: online scrub/repair support Amir Goldstein
2017-01-22 5:01 ` Darrick J. Wong
2017-01-22 6:10 ` Amir Goldstein
2017-01-26 5:08 ` Eryu Guan [this message]
2017-01-26 6:44 ` Darrick J. Wong
2017-01-26 7:26 ` Eryu Guan
2017-01-26 7:53 ` Darrick J. Wong
2017-01-27 1:41 ` Eryu Guan
2017-01-27 9:22 ` Darrick J. Wong
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=20170126050838.GN1859@eguan.usersys.redhat.com \
--to=eguan@redhat.com \
--cc=darrick.wong@oracle.com \
--cc=fstests@vger.kernel.org \
--cc=linux-xfs@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 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).