From: Dave Chinner <david@fromorbit.com>
To: Jeff Mahoney <jeffm@suse.com>
Cc: Brian Foster <bfoster@redhat.com>,
linux-btrfs <linux-btrfs@vger.kernel.org>,
fstests@vger.kernel.org
Subject: Re: [PATCH] xfstests: generic: test for discard properly discarding unused extents
Date: Thu, 2 Apr 2015 09:12:02 +1100 [thread overview]
Message-ID: <20150401221202.GE28621@dastard> (raw)
In-Reply-To: <551C4073.8010201@suse.com>
On Wed, Apr 01, 2015 at 03:01:07PM -0400, Jeff Mahoney wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 4/1/15 2:44 PM, Brian Foster wrote:
> > On Mon, Mar 30, 2015 at 03:11:06PM -0400, Jeff Mahoney wrote:
> >> This tests tests four conditions where discard can potentially
> >> not discard unused extents completely.
> >>
> >> We test, with -o discard and with fstrim, scenarios of removing
> >> many relatively small files and removing several large files.
> >>
> >> The important part of the two scenarios is that the large files
> >> must be large enough to span a blockgroup alone. It's possible
> >> for an entire block group to be emptied and dropped without an
> >> opportunity to discard individual extents as would happen with
> >> smaller files.
> >>
> >> The test confirms the discards have occured by using a sparse
> >> file mounted via loopback to punch holes and then check how many
> >> blocks are still allocated within the file.
> >>
> >> Signed-off-by: Jeff Mahoney <jeffm@suse.com> ---
> >
> > The code looks mostly Ok to me, a few notes below. Those aside,
> > this is a longish test. It takes me about 8 minutes to run on my
> > typical low end vm.
>
> My test hardware is a 16 core / 16 GB RAM machine using a commodity
> SSD. It ran pretty quickly.
Yup, I have a test VM like that, too. However, like many other
people, I also have small VMs that share single spindles with other
test VMs, so we need to cater for them, too.
> >> + if [ "$FSTYP" = "btrfs" ]; then
> >> + _run_btrfs_util_prog filesystem sync $tmpdir
> >> + fi
> >> + sync
> >> + sync
> >
> > Any reason for the double syncs?
>
> Superstition? IIRC, at one point in what is probably the ancient past,
> btrfs needed two syncs to be safe. I kept running into false failures
> without both a sync and the btrfs filesystem sync, so I just hit the
> "no really, just do it" button.
Urk. If btrfs requires two sync passes to really sync data/metadata,
then that's a bug that needs to be fixed. Let's not encode
superstition or work around bugs that really should be fixed in the
test code....
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2015-04-01 22:12 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-30 19:11 [PATCH] xfstests: generic: test for discard properly discarding unused extents Jeff Mahoney
2015-04-01 18:44 ` Brian Foster
2015-04-01 19:01 ` Jeff Mahoney
2015-04-01 22:12 ` Dave Chinner [this message]
2015-04-02 11:49 ` Brian Foster
2015-04-02 12:33 ` Lukáš Czerner
2015-04-02 14:44 ` Jeff Mahoney
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=20150401221202.GE28621@dastard \
--to=david@fromorbit.com \
--cc=bfoster@redhat.com \
--cc=fstests@vger.kernel.org \
--cc=jeffm@suse.com \
--cc=linux-btrfs@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).