From: Ted Ts'o <tytso@mit.edu>
To: Jeff Moyer <jmoyer@redhat.com>
Cc: Lukas Czerner <lczerner@redhat.com>,
eshishki@redhat.com, rwheeler@redhat.com,
linux-ext4@vger.kernel.org, sandeen@redhat.com
Subject: Re: Ext4: batched discard support - simplified version
Date: Fri, 23 Jul 2010 13:00:05 -0400 [thread overview]
Message-ID: <20100723170005.GJ13090@thunk.org> (raw)
In-Reply-To: <x49bp9yjjed.fsf@segfault.boston.devel.redhat.com>
On Fri, Jul 23, 2010 at 11:40:58AM -0400, Jeff Moyer wrote:
>
> You are right, and we have to consider thinly provisioned luns, as well.
> The only case I can think of where it makes sense to issue those
> discards immediately is if you are running tight on allocated space in
> your thinly provisioned lun. Aside from that, I'm not sure why you
> would want to send those commands down with every journal commit,
> instead of batched daily, for example. But, I can certainly understand
> wanting to allow this flexibility.
The two reasons I could imagine is to give more flexibility to the
wear leveling algorithms (depending on how often you are turning over
files --- i.e., deleting blocks and then reusing them), and to
minimize latency (it might be nicer for the system to send down the
deleted blocks on a continuing basis rather than to send them down all
at once).
The other issue is that by sending TRIM commands for all free extents,
even those that haven't been recently been released, the flash
translation layer needs to look up a large number of blocks in its
translation table to see if it needs to update it. This can end up
burning CPU unnecessarily, especially for those flash devices (such as
FusionIO, for example) manage their FTL using the host CPU.
So this is one of the reasons why I want to leave some flexibility
here; BTW, for some systems, it may make sense for the FITRIM ioctl to
throttle the rate at which it locks block groups and sends down TRIM
requests so it doesn't end up causing performance hiccups for live
applications while the FITRIM ioctl is running.
- Ted
next prev parent reply other threads:[~2010-07-23 17:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-07 7:53 Ext4: batched discard support - simplified version Lukas Czerner
2010-07-07 7:53 ` [PATCH 1/2] Add ioctl FITRIM Lukas Czerner
2010-07-07 7:53 ` [PATCH 2/2] Add batched discard support for ext4 Lukas Czerner
2010-07-14 8:33 ` Dmitry Monakhov
2010-07-14 9:40 ` Lukas Czerner
2010-07-14 10:03 ` Dmitry Monakhov
2010-07-14 11:43 ` Lukas Czerner
2010-07-23 14:36 ` Ext4: batched discard support - simplified version Ted Ts'o
2010-07-23 15:13 ` Jeff Moyer
2010-07-23 15:19 ` Ted Ts'o
2010-07-23 15:40 ` Jeff Moyer
2010-07-23 17:00 ` Ted Ts'o [this message]
2010-07-24 16:31 ` Ric Wheeler
2010-07-23 15:30 ` Greg Freemyer
2010-07-26 10:30 ` Lukas Czerner
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=20100723170005.GJ13090@thunk.org \
--to=tytso@mit.edu \
--cc=eshishki@redhat.com \
--cc=jmoyer@redhat.com \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=rwheeler@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.