All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Richard W.M. Jones" <rjones@redhat.com>
To: Eric Sandeen <sandeen@redhat.com>, pbonzini@redhat.com
Cc: linux-ext4@vger.kernel.org
Subject: Re: fstrim has no effect on a just-mounted filesystem
Date: Wed, 12 Mar 2014 10:17:44 +0000	[thread overview]
Message-ID: <20140312100507.GA19635@redhat.com> (raw)
In-Reply-To: <20140311233047.GX1346@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 1885 bytes --]

On Tue, Mar 11, 2014 at 11:30:47PM +0000, Richard W.M. Jones wrote:
> On Tue, Mar 11, 2014 at 06:09:28PM -0500, Eric Sandeen wrote:
> > On Tue, Mar 11, 2014, Richard W.M. Jones wrote:
> > > However just the act of doing the tracing *caused* the trim to happen
> > > properly in the underlying disk.
> > 
> > that sounds very strange...
> 
> Thanks Eric.
> 
> FYI the libguestfs / virt-sparsify patch series that motivates this is
> here:
> 
> https://www.redhat.com/archives/libguestfs/2014-March/thread.html#00091
> 
> Even with the greatly reduced set of traces (see attached), just the
> act of tracing seems to have made trimming work properly.  The output
> file has been trimmed properly from 926 MB to 819 MB:

I did a bit more testing on this.

It appears we are sure that the ext4 ioctl FITRIM is sending discard
requests.

However fstrim doesn't happen reliably.

  fstrim + blktrace       works reliably
  fstrim + fsync          unreliable, usually fails to trim
  fstrim + sync           unreliable, usually fails to trim
  fstrim + umount         unreliable, usually fails to trim
  fstrim + sleep 10       unreliable, usually fails to trim
  ( fstrim + sleep 10 ) x 3  unreliable, usually fails to trim
  fstrim on its own       unreliable, usually fails to trim

Somewhere, the discard requests are disappearing in the stack (or more
likely, being delayed).  blktrace/trace-cmd somehow forces them out.
But fsync/sync/umount/sleep does not.  They might be stuck in qemu too ...

Is there any further test I can try here?

Is there a way to force out discard requests?

qemu cache mode is set to writeback.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

[-- Attachment #2: test-fstrim.pl --]
[-- Type: application/x-perl, Size: 3806 bytes --]

  reply	other threads:[~2014-03-12 10:17 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-11 21:39 fstrim has no effect on a just-mounted filesystem Richard W.M. Jones
2014-03-11 21:47 ` Eric Sandeen
2014-03-11 22:00   ` Richard W.M. Jones
2014-03-11 22:04     ` Richard W.M. Jones
2014-03-11 22:08     ` Eric Sandeen
2014-03-11 22:59       ` Richard W.M. Jones
2014-03-11 23:07         ` Richard W.M. Jones
2014-03-11 23:09           ` Eric Sandeen
2014-03-11 23:30             ` Richard W.M. Jones
2014-03-12 10:17               ` Richard W.M. Jones [this message]
2014-03-12 13:42                 ` Richard W.M. Jones
2014-03-12 18:10                 ` Paolo Bonzini
2014-03-12 18:24                   ` 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=20140312100507.GA19635@redhat.com \
    --to=rjones@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=sandeen@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.