Hi!
While debugging an issue, we found out that generic/399 seems to rely on
a behavior that is specific to ext4 in the following section of code:
----------------8<--------snip--------8<------------------------------
#
# Write files of 1 MB of all the same byte until we hit ENOSPC. Note
that we
# must not create sparse files, since the contents of sparse files are not
# stored on-disk. Also, we create multiple files rather than one big file
# because we want to test for reuse of per-file keys.
#
total_file_size=0
i=1
while true; do
file=$SCRATCH_MNT/encrypted_dir/file$i
if ! $XFS_IO_PROG -f $file -c 'pwrite 0 1M' &> $tmp.out; then
if ! grep -q 'No space left on device' $tmp.out; then
echo "FAIL: unexpected pwrite failure"
cat $tmp.out
elif [ -e $file ]; then
total_file_size=$((total_file_size + $(stat -c %s $file)))
fi
break
fi
total_file_size=$((total_file_size + $(stat -c %s $file)))
i=$((i + 1))
if [ $i -gt $fs_size_in_mb ]; then
echo "FAIL: filesystem never filled up!"
break
fi
done
----------------8<--------snip--------8<------------------------------
What happens with ext4 is that the xfs_io command gives a nonzero exit
value not when the pwrite command fails with ENOSPC but during the
*next* iteration when opening the file fails with ENOSPC. Turns out the
pwrite command failing does not cause xfs_io to give a nonzero exit value.
With one of our filesystems, pwrite fails considerably earlier than we
become unable to create new files, making this test case misbehave as
the pwrite failure is basically ignored while we keep creating new empty
files.
While I understand that supporting out-of-tree filesystems is not what
is done in fstests land, this issue looks like it is generic enough to
at least warrant some discussion. It is not inconceivable at all that an
in-tree filesystem could have something else than this specific ext4
behavior.
The issue itself could either be fixed in xfsprogs, allowing the pwrite
failure to propagate to the exit value in some manner, or in fstests by
having an alternate/additional mechanism for detecting the ENOSPC (we do
have some simple, nonintrusive ideas, if there is interest).
Thanks,
Ari Sundholm
ari@xxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe fstests" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
