On 04/26/2013 01:45 PM, Eric Sandeen wrote:
test 284 had... some issues.
First, it took so long nobody ran it; so shorten the extent
count by a factor of about 100.
Having fixed that, we see failures in 2 cases; when start or
len is -1, but the golden output file didn't have error
output, as if they should pass.
I'm going to argue that these *should* both fail; start = -1
has no real meaning. length = -1 might mean "the rest
of the file" but if that's what you really want, just
don't specify -l.
So add failure output for those cases.
Send all command output to $seq.full, in case that changes
in the future; just capture the return value.
Then remove the return value echo on failure (50?) because
who knows when that might change to some other magic value.
Ok, then when defrag actually works, old defrag returned
"20" (because?) but a recent commit changed it to 0.
So accommodate that too.
And remove a stray "HAVE_DEFRAG=1" while we're at it.
That variable is never used.
So should I be seeing failures with
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 cxfsxe4 3.9.0+
MKFS_OPTIONS -- /dev/sdk2
MOUNT_OPTIONS -- /dev/sdk2 /mnt/scratch
btrfs/284 - output mismatch (see
--- tests/btrfs/284.out 2013-05-14 09:31:35.000000000 -0500
+++ /usr/src/rcj/xfstests/results/btrfs/284.out.bad 2013-05-14
@@ -6,7 +6,6 @@
btrfs filesystem defragment failed!
a single file | start > file size && 0 < len < file size | off
a single file | start = 0 && len < 0 | off (should fail)
-btrfs filesystem defragment failed!
a single file | start = 0 && len > file size | off
a single file | start = 0 && 0 < len < file size | off
a directory | default | off
(Run 'diff -u tests/btrfs/284.out
/usr/src/rcj/xfstests/results/btrfs/284.out.bad' to see the entire diff)
Failed 1 of 1 tests