public inbox for fstests@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Ari Sundholm <ari@tuxera.com>
Cc: fstests@vger.kernel.org, Emil Karlson <jkarlson@tuxera.com>
Subject: Re: generic/399 and xfs_io pwrite command
Date: Tue, 5 Dec 2017 09:28:42 +1100	[thread overview]
Message-ID: <20171204222842.GX4094@dastard> (raw)
In-Reply-To: <7235f31f-5427-ff12-11f9-cba98431e71c@tuxera.com>

On Thu, Nov 30, 2017 at 04:21:47PM +0200, 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.

That implies ext4 is returning zero bytes written to the pwrite()
call rather than ENOSPC. i.e.:

                bytes = do_pwrite(file->fd, off, cnt, buffersize,
                                pwritev2_flags);
                if (bytes == 0)
                        break;
                if (bytes < 0) {
                        perror("pwrite");
                        return -1;
                }

So if it's exiting with no error, then we can't have got an error
from ext4 at ENOSPC. If that's the case, it probably should be
considered an ext4 bug, not an issue with xfs_io...

Can you run this under strace to determine if this is what is really
happening? 

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  parent reply	other threads:[~2017-12-04 22:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171204222842.GX4094@dastard \
    --to=david@fromorbit.com \
    --cc=ari@tuxera.com \
    --cc=fstests@vger.kernel.org \
    --cc=jkarlson@tuxera.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox