generic/399: don't rely on xfs_io exit status
authorEric Biggers <ebiggers@google.com>
Mon, 8 Jul 2019 20:32:39 +0000 (13:32 -0700)
committerEryu Guan <guaneryu@gmail.com>
Fri, 12 Jul 2019 05:33:50 +0000 (13:33 +0800)
commit856f357c6a5cbd7110a24fafa3fa6be65c145501
tree04acce0a5ceda700816e2362c4d5fe6fb2b3cdca
parent7ef6a36702b253808e629e90e6677d3b86a0a3ea
generic/399: don't rely on xfs_io exit status

Unexpectedly, 'xfs_io -f $file -c "pwrite 0 1M"' exits with failure
status if the file can't be created, but exits with success status if an
error occurs actually writing data.  As discussed previously, xfs_io's
exit status has always been broken, and it will be difficult to fix:
https://marc.info/?l=linux-xfs&m=151269053129101&w=2

Because of this, generic/399 fails on ext4 if "-I 256" (256-byte inodes)
is specified in the mkfs options, e.g. with 'kvm-xfstests -c ext4/adv
generic/399'.  This is because the test tries to fill a filesystem
entirely with 1 MiB encrypted files, and it expects the xfs_io commands
to start failing when no more files should be able to fit.  But when the
filesystem supports in-inode xattrs, no blocks need to be allocated for
the encryption xattrs, so empty encrypted files can continue to be
created even after all the filesystem's blocks are in-use.

For better or worse, the convention for xfstests is to ignore the exit
status of xfs_io and instead rely on the printed error messages.  Thus,
other tests don't run into this problem.  So for now, let's fix the test
failure by making generic/399 do the same.

Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
tests/generic/399