Re: mysterious test failure when running xfstests on XFS

Re: mysterious test failure when running xfstests on XFS

[Darrick J. Wong]

On Fri, Jun 28, 2019 at 04:21:17PM -0400, Theodore Ts'o wrote:
> When trying to make sure a change to a test works on other file
> systems, I noticed the failure:
> 
> xfs_db: error - read only 0 of 32768 bytes
> xfs_db: /tmp/1577.img is invalid (cannot read first 512 bytes)
> 
> When I tried tracking down where this failure was coming from, I found
> this:
> 
> ++ export 'XFS_IO_PROG=/root/xfstests/bin/xfs_io -i'
> ++ XFS_IO_PROG='/root/xfstests/bin/xfs_io -i'
> ++ '[' xfs == xfs ']'
> ++ touch /tmp/10216.img
> ++ /root/xfstests/bin/mkfs.xfs -d file,name=/tmp/10216.img,size=512m
> ++ /root/xfstests/bin/xfs_db -x -c 'uuid generate' /tmp/10216.img
> ++ grep -q 'invalid UUID\|supported on V5 fs'
> xfs_db: error - read only 0 of 32768 bytes
> xfs_db: /tmp/10216.img is invalid (cannot read first 512 bytes)
> ++ rm -f /tmp/10216.img
> 
> Apparently the issue is that the mkfs.xfs is failing, but in init_rc
> we redirect the output to /dev/null:
> 
> 		touch /tmp/$$.img
> 		$MKFS_XFS_PROG -d file,name=/tmp/$$.img,size=512m >/dev/null 2>&1
> 		# xfs_db will return 0 even if it can't generate a new uuid, so
> 		# check the output to make sure if it can change UUID of V5 xfs
> 		$XFS_DB_PROG -x -c "uuid generate" /tmp/$$.img \
> 			| grep -q "invalid UUID\|supported on V5 fs" \
> 			&& export XFS_COPY_PROG="$XFS_COPY_PROG -d"
> 		rm -f /tmp/$$.img
> 
> From a test script:
> 
> rm -f $IMAGE
> + rm -f /tmp/10216.img
> touch $IMAGE
> + touch /tmp/10216.img
> ./xfsprogs-dev/mkfs/mkfs.xfs  -d file,name=$IMAGE,size=512m
> + ./xfsprogs-dev/mkfs/mkfs.xfs -d file,name=/tmp/10216.img,size=512m
> mkfs.xfs: Use the -f option to force overwrite.

Hmmm, mkfs.xfs always requires -f if it was built without blkid since it
then won't have the ability to determine if there's already a filesystem
on the device you're trying to format.  Was your xfsprogs was built
without blkid?

$ strings /opt/root/xfstests/bin/mkfs.xfs | grep blkid
$ ldd /opt/root/xfstests/bin/mkfs.xfs
        not a dynamic executable

Yep.  Rummaging through the xfstests-bld repo... aha!

     export LOCAL_CONFIGURE_OPTIONS="$cross --prefix=/ --disable-lib64 --disable-gettext --disable-libicu --disable-blkid" ; \

/me traces it to this commit:

24c24367f36a36 ("build-all: disable blkid when building xfsprogs")

2019-02-19, I guess nobody's updated their xfstests-bld repos since
before then; I certainly hadn't. :)

Hmm... these days xfsprogs really wants to be built with libblkid since
(a) that's the configuration that most distros ship and (b) some of the
online utilities (like xfs_scrub) really /do/ want blkid information to
try to guess the level of parallelism of the device.

What's less clear is how to proceed from here -- should kvm-xfstests
download and build upstream libblkid and then point the xfsprogs build
at it?

I suppose we could change xfstests to detect if mkfs isn't linked
against libblkid and inject a "-f" into XFS_MKFS_PROG, though that could
cause other problems with tests that might not be expecting non-force
mode.

--D

> 
> A simple way to reproduce this:
> 
> 1)  Download the root_fs.img.amd64:
> 
> https://mirrors.edge.kernel.org/pub/linux/kernel/people/tytso/kvm-xfstests/root_fs.img.amd64
> 
> 2)  Run the command:
> 
> 	kvm-xfstests -I /tmp/root_fs.img.amd64 -c xfs generic/001
> 
> 3)  Observe the failure:
> 
> generic/001 2s ... 	[16:15:48][    5.187808] run fstests generic/001 at 2019-06-28 16:15:48
>  [16:15:51]- output mismatch (see /results/xfs/results-4k/generic/001.out.bad)
>     --- tests/generic/001.out	2019-06-10 00:02:54.000000000 -0400
>     +++ /results/xfs/results-4k/generic/001.out.bad	2019-06-28 16:15:51.631596912 -0400
>     @@ -1,4 +1,6 @@
>      QA output created by 001
>     +xfs_db: error - read only 0 of 32768 bytes
>     +xfs_db: /tmp/1577.img is invalid (cannot read first 512 bytes)
>      cleanup
>      setup ....................................
>      iter 1 chain ... check ....................................
>     ...
>     (Run 'diff -u /root/xfstests/tests/generic/001.out /results/xfs/results-4k/generic/001.out.bad'  to)
> Ran: generic/001
> Failures: generic/001
> 
> I know this used to work, but I'm not sure at what point this started
> failing for me.   Is there anything obvious?
> 
> 
> 						- Ted

Re: mysterious test failure when running xfstests on XFS

[Theodore Ts'o]

On Fri, Jun 28, 2019 at 04:21:17PM -0400, Theodore Ts'o wrote:
> 
> rm -f $IMAGE
> + rm -f /tmp/10216.img
> touch $IMAGE
> + touch /tmp/10216.img
> ./xfsprogs-dev/mkfs/mkfs.xfs  -d file,name=$IMAGE,size=512m
> + ./xfsprogs-dev/mkfs/mkfs.xfs -d file,name=/tmp/10216.img,size=512m
> mkfs.xfs: Use the -f option to force overwrite.

I figured out.  The problem is I'm building xfsprogs with
--disable-blkid.  This was for historical reasons, back when I was
trying to use a fully hermetic build, since the cross compiler I was
using would not include anything in /usr/include.  I'm no longer
trying to use the Android Native Development Kit (NDK), so maybe I'll
give up on this goal and use the system-proivded blkid.  (Or I'll
build util-linux in xfstests-bld and solve the problem that way.)

In any case, here's a patch to fix this.

						- Ted


>From 4767f770ff5d60635164410e7834e5aece505424 Mon Sep 17 00:00:00 2001
From: Theodore Ts'o <tytso@mit.edu>
Date: Fri, 28 Jun 2019 17:21:50 -0400
Subject: [PATCH] libfrog: fix check_overwrite() when blkid is not available

A return value of 0 means "nothing found"; the code was incorrectly
returning 1 instead.

Signed-off-by: Theodore Ts'o <tytso@mit.edu>
---
 libfrog/topology.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libfrog/topology.c b/libfrog/topology.c
index cac164f3..c2e93e65 100644
--- a/libfrog/topology.c
+++ b/libfrog/topology.c
@@ -264,7 +264,7 @@ int
 check_overwrite(
 	const char	*device)
 {
-	return 1;
+	return 0;
 }
 
 static void blkid_get_topology(
-- 
2.22.0