From: Dave Chinner <david@fromorbit.com>
To: Brian Foster <bfoster@redhat.com>
Cc: fstests@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH v3] xfstests: test speculative preallocation reclaim on ENOSPC/EDQUOT
Date: Wed, 18 Jun 2014 10:43:55 +1000 [thread overview]
Message-ID: <20140618004355.GZ4453@dastard> (raw)
In-Reply-To: <1402508170-61125-1-git-send-email-bfoster@redhat.com>
On Wed, Jun 11, 2014 at 01:36:10PM -0400, Brian Foster wrote:
> XFS can allocate significant amounts of space to files via speculative
> preallocation. Such preallocation may not be reclaimed automatically on
> file close() if a file is repeatedly opened and extended. For smaller
> filesystems with relatively large and slow growing files, this
> preallocation can linger for some time, including contributing to out of
> space conditions.
>
> Create a situation where an fs is near out of space while several files
> still have lingering, significant preallocations. Verify that new
> writers reclaim the preallocated space rather than return ENOSPC. Repeat
> a similar test for quota limits and EDQUOT.
>
> Signed-off-by: Brian Foster <bfoster@redhat.com>
Hi Brian,
My test machines all fail this test with output like this:
xfs/014 - output mismatch (see /home/dave/src/xfstests-dev/results//xfs/014.out.bad)
--- tests/xfs/014.out 2014-06-18 09:32:59.000000000 +1000
+++ /home/dave/src/xfstests-dev/results//xfs/014.out.bad 2014-06-18 10:27:10.000000000 +1000
@@ -1,2 +1,7 @@
QA output created by 014
Silence is golden.
+/mnt/scratch/014.mnt/file.0: No space left on device
+pwrite64: No space left on device
+/mnt/scratch/014.mnt/file.2: No space left on device
+pwrite64: No space left on device
+pwrite64: Disk quota exceeded
.....
or this from a 1k block size filesystem:
xfs/014 - output mismatch (see /home/dave/src/xfstests-dev/results//xfs/014.out.bad)
--- tests/xfs/014.out 2014-06-18 09:32:59.000000000 +1000
+++ /home/dave/src/xfstests-dev/results//xfs/014.out.bad 2014-06-18 10:29:15.000000000 +1000
@@ -1,2 +1,7 @@
QA output created by 014
Silence is golden.
+pwrite64: No space left on device
+pwrite64: No space left on device
+pwrite64: No space left on device
+pwrite64: No space left on device
+pwrite64: Disk quota exceeded
.....
I'm still going to commit the test as it stands, but could you see
if you can reproduce this or suggest hints as to where it might be
going wrong?
FWIW, patches to tee the stderr output to both the golden output and
the $seqres.full file will make it much easier to determine what
write is failing....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-06-18 0:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-11 17:36 [PATCH v3] xfstests: test speculative preallocation reclaim on ENOSPC/EDQUOT Brian Foster
2014-06-18 0:43 ` Dave Chinner [this message]
2014-06-18 12:28 ` Brian Foster
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=20140618004355.GZ4453@dastard \
--to=david@fromorbit.com \
--cc=bfoster@redhat.com \
--cc=fstests@vger.kernel.org \
--cc=xfs@oss.sgi.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