linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Mason <chris.mason@oracle.com>
To: Matthew Wilcox <willy@linux.intel.com>
Cc: Theodore Tso <tytso@mit.edu>, Jens Axboe <jens.axboe@oracle.com>,
	Ric Wheeler <rwheeler@redhat.com>,
	linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org
Subject: Re: Is TRIM/DISCARD going to be a performance problem?
Date: Mon, 11 May 2009 14:53:15 -0400	[thread overview]
Message-ID: <1242067995.13509.1.camel@localhost.localdomain> (raw)
In-Reply-To: <20090511184323.GA16885@linux.intel.com>

On Mon, 2009-05-11 at 11:43 -0700, Matthew Wilcox wrote:
> On Mon, May 11, 2009 at 01:18:45PM -0400, Chris Mason wrote:
> > For both btrfs and lvm, the filesystem is going to maintain free block
> > information based on logical block numbers.  The generic trim layer
> > should probably be based on a logical address that is stored per-bdi.
> > 
> > Then the bdi will need a callback to turn the logical address based trim
> > extent into physical extents on N number of physical device.
> > 
> > The tricky part is how will the FS decide a given block is actually
> > reusable.  We'll need a call back into the FS that indicates trim is
> > complete on a given logical extent.
> 
> Actually, that's the exact opposite of what you want.  You want to try
> to reuse blocks that are scheduled for trimming so that we never have to
> send the command at all.

Regardless of the optimal way to reuse blocks, we need some way of
knowing the discard is done, or at least sent down to the device in such
a way that any writes will happen after the discard and not before.

-chris





  reply	other threads:[~2009-05-11 18:53 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-09 21:14 Is TRIM/DISCARD going to be a performance problem? Theodore Ts'o
2009-05-10 16:53 ` Jörn Engel
2009-05-11  8:37   ` Theodore Tso
2009-05-11 10:06     ` Jörn Engel
2009-05-11 10:18       ` Jens Axboe
2009-05-11 15:43         ` Jeff Garzik
2009-05-11 11:27       ` Theodore Tso
2009-05-11 12:09         ` Theodore Tso
2009-05-11 13:10           ` Greg Freemyer
2009-05-11 13:39             ` Matthew Wilcox
2009-05-11 14:27             ` Theodore Tso
2009-05-11 14:29               ` Ric Wheeler
2009-05-11 14:50                 ` Theodore Tso
2009-05-11 14:58                   ` Ric Wheeler
2009-05-11 15:00                   ` Matthew Wilcox
2009-05-11 18:47                     ` Greg Freemyer
2009-05-11 19:22                       ` Andreas Dilger
2009-05-11 23:38                       ` Neil Brown
2009-05-12 13:28                         ` Greg Freemyer
2009-05-11 13:15           ` Ric Wheeler
2010-04-24 17:11           ` Phillip Susi
2009-05-11 12:43         ` Jörn Engel
2009-05-11 12:48           ` Matthew Wilcox
     [not found]             ` <f3177b9e0905111433i40e41c90r920d7ccf36442ffd@mail.gmail.com>
2009-05-11 22:03               ` Chris Worley
2009-05-11 16:30       ` Chris Worley
2009-05-11  8:12 ` Jens Axboe
2009-05-11  8:41   ` Theodore Tso
2009-05-11  8:49     ` Jens Axboe
2009-05-11 17:18     ` Chris Mason
2009-05-11 18:43       ` Matthew Wilcox
2009-05-11 18:53         ` Chris Mason [this message]
2009-05-11 19:19           ` Theodore Tso
2009-05-29 10:52         ` Florian Weimer

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=1242067995.13509.1.camel@localhost.localdomain \
    --to=chris.mason@oracle.com \
    --cc=jens.axboe@oracle.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=rwheeler@redhat.com \
    --cc=tytso@mit.edu \
    --cc=willy@linux.intel.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).