Re: generic/399 and xfs_io pwrite command

Goldwyn Rodrigues
2017-12-04T19:56:57Z

On 11/30/2017 08:21 AM, Ari Sundholm wrote:
> 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).

There is a new option added in xfs_io pwrite command called -O or
perform the operation once, for incomplete writes so as to get the
number of bytes written so far, as opposed to the final error. Calling
it again on a full filesystem with -O should give a ENOSPC error. Can
calling pwrite with -O multiple times be used for the purpose?

--
Goldwyn