public inbox for fstests@vger.kernel.org
 help / color / mirror / Atom feed
* generic/399 and xfs_io pwrite command
@ 2017-11-30 14:21 Ari Sundholm
  2017-12-04 19:56 ` Goldwyn Rodrigues
  2017-12-04 22:28 ` Dave Chinner
  0 siblings, 2 replies; 13+ messages in thread
From: Ari Sundholm @ 2017-11-30 14:21 UTC (permalink / raw)
  To: fstests; +Cc: Emil Karlson

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@tuxera.com

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2017-12-24 19:51 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-11-30 14:21 generic/399 and xfs_io pwrite command Ari Sundholm
2017-12-04 19:56 ` Goldwyn Rodrigues
2017-12-04 22:28 ` Dave Chinner
2017-12-05 14:23   ` Ari Sundholm
2017-12-05 21:18     ` Dave Chinner
2017-12-06  0:26       ` [PATCH] xfs_io: fix exitcode handling (was Re: generic/399 and xfs_io pwrite command) Dave Chinner
2017-12-07 14:05         ` Brian Foster
2017-12-07 23:46           ` Dave Chinner
2017-12-08 14:15             ` Brian Foster
2017-12-08 22:52               ` Dave Chinner
2017-12-24 19:51           ` Eric Sandeen
2017-12-14 12:11         ` Ari Sundholm
2017-12-15 14:26           ` Ari Sundholm

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox