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
> >
> >
