Linux XFS filesystem development
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
Cc: Zorro Lang <zlang@redhat.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 09:37:11 -0700	[thread overview]
Message-ID: <20190918163711.GX2229799@magnolia> (raw)
In-Reply-To: <7b5d5797-afff-90bc-0131-38fd13eced34@cn.fujitsu.com>

On Wed, Sep 18, 2019 at 11:24:47AM +0800, Yang Xu wrote:
> 
> 
> on 2019/09/18 10:59, Zorro Lang wrote:
> > 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.
> Yes. I also found running _scratch_mkfs_xfs in xfs/030 can slove this
> problem yesterday. Or, we can adjust _try_wipe_scratch_devs order in
> check(But I dont't have enough reason to explain why adjust it). as below:

(Yeah, I don't see any obvious reason why that would change outcomes...)

> --- a/check
> +++ b/check
> @@ -753,7 +753,6 @@ for section in $HOST_OPTIONS_SECTIONS; do
>                         # _check_dmesg depends on this log in dmesg
>                         touch ${RESULT_DIR}/check_dmesg
>                 fi
> -               _try_wipe_scratch_devs > /dev/null 2>&1
>                 if [ "$DUMP_OUTPUT" = true ]; then
>                         _run_seq 2>&1 | tee $tmp.out
>                         # Because $? would get tee's return code
> @@ -799,7 +798,7 @@ for section in $HOST_OPTIONS_SECTIONS; do
>                 # Scan for memory leaks after every test so that associating
>                 # a leak to a particular test will be as accurate as
> possible.
>                 _check_kmemleak || err=true
> -
> +               _try_wipe_scratch_devs > /dev/null 2>&1
>                 # test ends after all checks are done.
>                 $timestamp && _timestamp
>                 stop=`_wallclock`
> 
> > 
> > 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.
> > 
>  I am finding the reasion. It seems wipefs wipes important information and
> $DSIZE option(using single agcount or dsize, it also fails ) can not format
> disk completely. If we use other options, it can pass.

How does mkfs fail, specifically?

Also, what's your storage configuration?  And lsblk -D output?

--D

> > 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
> > failsYes. But I perfer to remove them because IMO they are useless.
> > 
> 
> > 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
> > 
> 
> 

  reply	other threads:[~2019-09-18 16:37 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
2019-09-18  3:24     ` Yang Xu
2019-09-18 16:37       ` Darrick J. Wong [this message]
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=20190918163711.GX2229799@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=fstests@vger.kernel.org \
    --cc=linux-xfs@vger.kernel.org \
    --cc=xuyang2018.jy@cn.fujitsu.com \
    --cc=zlang@redhat.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