Skip to contentSkip to conversation

generic/256 test failure?

DISCUSSION Theodore Ts'o 2 participants 3 messages Dec 11, 2014

lore
Share & tools
lore
#0 lore raw

I've been trying to debug generic/256 failing under ext4, and I realized that it's actually failing with xfs as well:

BEGIN TEST: XFS Wed Dec 10 19:36:38 EST 2014
Device: /dev/vdd
mk2fs options:
mount options:

FSTYP         -- xfs (non-debug)
PLATFORM      -- Linux/i686 kvm-xfstests 3.18.0-rc3-00029-g754c126
MKFS_OPTIONS  -- -f -bsize=4096 /dev/vdc

MOUNT_OPTIONS -- /dev/vdc /vdc

generic/256 [19:36:40] [19:37:31] - output mismatch (see /results/results-xfs/generic/256.out.bad)
--- tests/generic/256.out 2014-12-10 18:15:22.000000000 -0500
+++ /results/results-xfs/generic/256.out.bad 2014-12-10 19:37:32.002538550 -0500
@@ -1 +1,2229 @@
QA output created by 256
+wrote 1073741824/1073741824 bytes at offset 0
+1 GiB, 262144 ops; 0:00:11.00 (92.306 MiB/sec and 23630.3397 ops/sec)
+pwrite64: No space left on device
+pwrite64: No space left on device
+pwrite64: No space left on device
+pwrite64: No space left on device
...
(Run 'diff -u tests/generic/256.out /results/results-xfs/generic/256.out.bad' to see the entire diff)
Ran: generic/256
Failures: generic/256
Failed 1 of 1 tests

root@kvm-xfstests:~# blkid /dev/vdc
/dev/vdc: UUID="6a820f3b-109f-465e-941e-6bc2bfae6e42" TYPE="xfs"

This is failing with xfstests commit 6676905, and xfsprogs v3.2.2.

Is anyone else seeing this failure?

- Ted

#1 lore raw

I figured it out; the problem is that Debian uses /bin/dash as the default shell (which is good, it meant that most Debian systems didn't get screwed by the bash security hole). But it's also bad, because xfstests has a few /bin/bashisms. Normally, this isn't a problem because most of the scripts are started by #!/bin/bash. However, on my test system fsgqa had a shell of /dev/sh, and in Debian this is /bin/dash.

So there are a couple of ways I can fix this.

1) Document in README that fsgqa must use a shell of fsgqa to /bin/bash or some tests might fail.

2) Change _user_do() to use "su -s /bin/bash $qa_user ...".

3) Change tests/generic/256 so that instead of

_user_do "$XFS_IO_PROG -f -c \"pwrite 0 $file_size\" $dir/$file_count.bin &> /dev/null"

we use:

_user_do "$XFS_IO_PROG -f -c \"pwrite 0 $file_size\" $dir/$file_count.bin > /dev/null 2>&1"

or:

_user_do "$XFS_IO_PROG -f -c \"pwrite 0 $file_size\" $dir/$file_count.bin" &> /dev/null

Any preference which patch, if any, I should send? (If #1, then we probably document the fact that fsgqa must have a shell of bash).

Thanks,

- Ted

Reviewed-by Eric Sandeen
#2 lore raw
Quoted 4 lines · Theodore Ts'o

I figured it out; the problem is that Debian uses /bin/dash as the default shell (which is good, it meant that most Debian systems didn't get screwed by the bash security hole). But it's also bad, because xfstests has a few /bin/bashisms.

FYI, bash is required for xfstests - we made this explicit several years ago:

commit 771e69de67b138654a1f63258cfe4c1bf1c156ee

Author: Dave Chinner <[email protected]>
Date:   Wed Jan 20 10:27:08 2010 +1100

xfstests: Convert all tests to use /bin/bash

While most tests use /bin/sh, they are dependent on /bin/sh being a bash shell. Convert all the tests to execute via /bin/bash as it is much, much simpler than trying to debug and remove all the bashisms throughout the test code.

Quoted 9 lines

Normally, this isn't a problem
because most of the scripts are started by #!/bin/bash. However, on my test system fsgqa had a shell of /dev/sh, and in Debian this is /bin/dash.

So there are a couple of ways I can fix this.

1) Document in README that fsgqa must use a shell of fsgqa to /bin/bash or some tests might fail.

Please send a patch to do that.

Quoted 9 lines

2) Change _user_do() to use "su -s /bin/bash $qa_user ...".

3) Change tests/generic/256 so that instead of

   	  _user_do "$XFS_IO_PROG -f -c \"pwrite 0 $file_size\" $dir/$file_count.bin &> /dev/null"

we use:

   	  _user_do "$XFS_IO_PROG -f -c \"pwrite 0 $file_size\" $dir/$file_count.bin > /dev/null 2>&1"

That's consistent with all the redirections in the rest of the code, so it's probably a good idea to sanitise the test while this is in our minds.

Cheers,

Dave.

Signature · 2 lines
Dave Chinner
[email protected]