mysterious test failure when running xfstests on XFS

DISCUSSION Theodore Ts'o 2 participants 2 messages Jun 28, 2019 1 message not in the archive

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Theodore Ts'o

author

2019-06-28 21:35 UTC #1 lore raw

Quoted 8 lines · Theodore Ts'o

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

Quoted 1 line

From 4767f770ff5d60635164410e7834e5aece505424 Mon Sep 17 00:00:00 2001

From: Theodore Ts'o <[email protected]>
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 <[email protected]>

---
 libfrog/topology.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

libfrog/topology.c +1 -1

index cac164f3..c2e93e65 100644
@@ -264,7 +264,7 @@ int
 check_overwrite(
 	const char	*device)
 {
-	return 1;
+	return 0;
 }
 
 static void blkid_get_topology(

Signature · 1 line

2.22.0

Darrick J. Wong

2019-06-28 21:50 UTC #2 lore raw

In reply to a message not in the archive

Quoted 34 lines · Theodore Ts'o

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:

Quoted 7 lines

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

Quoted 34 lines

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