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 -- 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
