From: Zorro Lang <zlang@redhat.com>
To: "Darrick J. Wong" <darrick.wong@oracle.com>
Cc: "Xu, Yang" <xuyang2018.jy@cn.fujitsu.com>,
"fstests@vger.kernel.org" <fstests@vger.kernel.org>,
xfs <linux-xfs@vger.kernel.org>
Subject: Re: question of xfs/148 and xfs/149
Date: Wed, 18 Sep 2019 10:59:15 +0800 [thread overview]
Message-ID: <20190918025915.GK7239@dhcp-12-102.nay.redhat.com> (raw)
In-Reply-To: <20190917163933.GC736475@magnolia>
On Tue, Sep 17, 2019 at 09:39:33AM -0700, Darrick J. Wong wrote:
> [add linux-xfs to cc]
>
> On Tue, Sep 17, 2019 at 09:00:57AM +0000, Xu, Yang wrote:
> > HI All
> >
> > When I investigated xfs/030 failure on upstream kernel after mering
> > xfstests commit d0e484ac699f ("check: wipe scratch devices between
> > tests"), I found two similar cases(xfs/148,xfs/149).
xfs/030 is weird, I've found it long time ago.
If I do a 'whole disk mkfs' (_scratch_mkfs_xfs), before this sized mkfs:
_scratch_mkfs_xfs $DSIZE >/dev/null 2>&1
Everything looks clear, and test pass. I can't send a patch to do this,
because I don't know the reason.
I'm not familiar with xfs_repair so much, so I don't know what happens
underlying. I suppose the the part after the $DSIZE affect the xfs_repair,
but I don't know why the wipefs can cause that, wipefs only erase 4 bytes
at the beginning.
Darrick, do you know more about that?
Thanks,
Zorro
> >
> > xfs/148 is a clone of test 030 using xfs_prepair64 instead of xfs_repair.
> > xfs/149 is a clone of test 031 using xfs_prepair instead of xfs_repair
I'm not worried about it too much, due to it always 'not run' and never
fails:)
xfs/148 [not run] parallel repair binary xfs_prepair64 is not installed
xfs/149 [not run] parallel repair binary xfs_prepair is not installed
Ran: xfs/148 xfs/149
Not run: xfs/148 xfs/149
Passed all 2 tests
> >
> > But I don't find these two commands and know nothing about them. If
> > these commands have been obsoleted long time ago, I think we can
> > remove the two cases. Or may I miss something?
>
> <shrug> I think your analysis is correct, but let's see what the xfs
> list thinks.
>
> --D
>
> >
> > Thanks
> > Yang Xu
> >
> >
next prev parent reply other threads:[~2019-09-18 2:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <4BF2FD5A942B1C4B828DDAF5635768C1041AB0E2@G08CNEXMBPEKD02.g08.fujitsu.local>
2019-09-17 16:39 ` question of xfs/148 and xfs/149 Darrick J. Wong
2019-09-18 2:59 ` Zorro Lang [this message]
2019-09-18 3:24 ` Yang Xu
2019-09-18 16:37 ` Darrick J. Wong
2019-09-18 23:10 ` Darrick J. Wong
2019-09-19 5:20 ` Zorro Lang
2019-09-19 6:33 ` Darrick J. Wong
2019-09-19 6:59 ` Zorro Lang
2019-09-19 10:49 ` Yang Xu
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=20190918025915.GK7239@dhcp-12-102.nay.redhat.com \
--to=zlang@redhat.com \
--cc=darrick.wong@oracle.com \
--cc=fstests@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=xuyang2018.jy@cn.fujitsu.com \
/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