linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Richard W.M. Jones" <rjones@redhat.com>
To: Jeff Moyer <jmoyer@redhat.com>
Cc: linux-fsdevel@vger.kernel.org, pbonzini@redhat.com
Subject: Re: Making discard/fstrim reliable
Date: Wed, 2 Apr 2014 21:26:26 +0100	[thread overview]
Message-ID: <20140402202626.GP1302@redhat.com> (raw)
In-Reply-To: <x494n2bts7i.fsf@segfault.boston.devel.redhat.com>

On Wed, Apr 02, 2014 at 04:02:57PM -0400, Jeff Moyer wrote:
> "Richard W.M. Jones" <rjones@redhat.com> writes:
> > Yes and no.  We examine the partitions, logical volumes and so on in
> > order to get a list of mountable filesystems, and then the list is
> > iterated over in this loop.  The precise code for finding the
> > filesystems is here:
> >
> > https://github.com/libguestfs/libguestfs/blob/master/src/listfs.c#L45
> >
> > ^ That code is running on the host side.  It issues various calls to
> > the appliance side which are executed by code in multiple files here:
> >
> > https://github.com/libguestfs/libguestfs/tree/master/daemon
> 
> Sorry, that's a lot to take in.  Can you distill this down to exactly
> the parts involved in the problem you're seeing?  Pretend I don't know
> anything about libguestfs (I don't).

Libguestfs runs up a small appliance, running the daemon above.  The
library side sends the daemon commands which the daemon runs.  The
commands that are run map nearly 1-1 to the libguestfs API.

The test program is this:

  # Add the disk to qemu.
  $g->add_drive ($disk, format => $format, readonly => 0, discard => "enable");
  # Run qemu.
  $g->launch ();

  # Run mkfs -t ext4 /dev/sda in the appliance.
  $g->mkfs ("ext4", "/dev/sda");
  # Run mount -o nodiscard /dev/sda /
  # [This is different from my earlier description, but it is done
  # deliberately so rm doesn't trim the space, because the test is
  # trying to test fstrim, not rm.  Discard of rm is tested in another test.]
  $g->mount_options ("nodiscard", "/dev/sda", "/");

  # Create a 10000000 byte file /data containing '!' characters.
  $g->fill (33, 10000000, "/data");
  # Sync the (guest) disk.
  $g->sync ();

  # The host file is examined here.
  my $full_size = (stat ($disk))[12];

  # Remove the large data file.  Because of -o nodiscard this won't trim.
  $g->rm ("/data");
  # Run fstrim in the appliance.
  $g->fstrim ("/");

  # This issues a sync for the guest disk, and kills qemu.
  $g->shutdown ();

  # The host file is examined again.
  my $trimmed_size = (stat ($disk))[12];
  if ($full_size - $trimmed_size < 1000) {
    # then print an error and die
  }

> I suggest you create a golden image that you copy for each test that
> already has the data committed to it.  The test would then just issue
> the rm and discard.

Sure I'll try this.  Will take a little time to implement it and run
the tests in various environments.

> It's only 64MB in size, right?  That could certainly affect things!

So I'm guessing this is too small?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

  reply	other threads:[~2014-04-02 20:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-26 20:47 Making discard/fstrim reliable Richard W.M. Jones
2014-04-02 18:18 ` Jeff Moyer
2014-04-02 18:59   ` Richard W.M. Jones
2014-04-02 20:02     ` Jeff Moyer
2014-04-02 20:26       ` Richard W.M. Jones [this message]
2014-04-10 15:05       ` Richard W.M. Jones
2014-04-03 17:08 ` Lukáš Czerner
2014-04-03 17:23   ` Richard W.M. Jones
2014-04-03 17:57   ` Paolo Bonzini
2014-04-03 18:08     ` Richard W.M. Jones

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=20140402202626.GP1302@redhat.com \
    --to=rjones@redhat.com \
    --cc=jmoyer@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=pbonzini@redhat.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;
as well as URLs for NNTP newsgroup(s).