From: Jeff Moyer <jmoyer@redhat.com>
To: James Bottomley <James.Bottomley@suse.de>
Cc: Christoph Hellwig <hch@infradead.org>,
Matthew Wilcox <matthew@wil.cx>, Josef Bacik <josef@redhat.com>,
Lukas Czerner <lczerner@redhat.com>,
tytso@mit.edu, linux-ext4@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
sandeen@redhat.com
Subject: Re: [PATCH 1/2] fs: Do not dispatch FITRIM through separate super_operation
Date: Thu, 18 Nov 2010 12:22:46 -0500 [thread overview]
Message-ID: <x494obe4kd5.fsf@segfault.boston.devel.redhat.com> (raw)
In-Reply-To: <1290100750.3041.72.camel@mulgrave.site> (James Bottomley's message of "Thu, 18 Nov 2010 11:19:10 -0600")
James Bottomley <James.Bottomley@suse.de> writes:
> Not stepping into the debate: I'm happy to see punch go to the mapping
> data and FITRIM pick it up later.
>
> However, I think it's time to question whether we actually still want to
> allow online discard at all. Most of the benchmarks show it to be a net
Define online discard, please.
> lose to almost everything (either SSD or Thinly Provisioned arrays), so
> it's become an "enable this to degrade performance" option with no
> upside.
Some SSDs very much require TRIMming to perform well as they age. If
you're suggesting that we move from doing discards in journal commits to
a batched discard, like the one Lukas implemented, then I think that's
fine. If we need to reintroduce the finer-grained discards due to some
hardware changes in the future, we can always do that.
Cheers,
Jeff
next prev parent reply other threads:[~2010-11-18 17:22 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-18 7:36 [PATCH 1/2] fs: Do not dispatch FITRIM through separate super_operation Lukas Czerner
2010-11-18 7:36 ` [PATCH 2/2] ext4: Add EXT4_IOC_TRIM ioctl to handle batched discard Lukas Czerner
2010-11-19 16:19 ` Ted Ts'o
2010-11-19 16:26 ` Lukas Czerner
2010-11-20 1:37 ` Ted Ts'o
2010-11-18 13:06 ` [PATCH 1/2] fs: Do not dispatch FITRIM through separate super_operation Matthew Wilcox
2010-11-18 13:48 ` Josef Bacik
2010-11-18 14:19 ` Matthew Wilcox
2010-11-18 14:29 ` Christoph Hellwig
2010-11-18 17:19 ` James Bottomley
2010-11-18 17:22 ` Jeff Moyer [this message]
2010-11-18 17:41 ` James Bottomley
2010-11-18 20:04 ` Greg Freemyer
2010-11-18 21:42 ` Mark Lord
2010-11-18 21:44 ` Mark Lord
2010-11-18 21:50 ` James Bottomley
2010-11-18 22:07 ` Mark Lord
2010-11-19 1:33 ` Ted Ts'o
2010-11-19 3:44 ` Mark Lord
[not found] ` <4CE5F2A1.2000009@teksavvy.com>
2010-11-19 13:58 ` Jeff Moyer
2010-11-18 23:52 ` Martin K. Petersen
2010-11-19 0:34 ` Mark Lord
2010-11-19 1:16 ` Greg Freemyer
2010-11-19 11:55 ` Christoph Hellwig
2010-11-19 14:01 ` Mark Lord
2010-11-19 14:06 ` Christoph Hellwig
2010-11-19 14:48 ` Mark Lord
2010-11-19 14:54 ` Christoph Hellwig
2010-11-19 15:24 ` Mark Lord
2010-11-19 15:34 ` Christoph Hellwig
2010-11-19 16:20 ` Greg Freemyer
2010-11-19 16:38 ` Christoph Hellwig
2010-11-19 18:06 ` Lukas Czerner
2010-11-19 18:10 ` Lukas Czerner
2010-11-19 18:14 ` Lukas Czerner
2010-11-19 19:29 ` Chris Mason
2010-11-19 1:49 ` Martin K. Petersen
2010-11-19 3:42 ` Mark Lord
2010-11-18 18:05 ` Jamie Lokier
2010-11-18 19:32 ` Markus Trippelsdorf
2010-11-18 21:45 ` Mark Lord
2010-11-18 21:50 ` Markus Trippelsdorf
2010-11-18 22:09 ` Mark Lord
2010-11-18 17:35 ` Lukas Czerner
2010-11-19 12:16 ` Steven Whitehouse
2010-11-19 13:53 ` Mark Lord
2010-11-19 14:02 ` Ted Ts'o
2010-11-19 14:10 ` Christoph Hellwig
2010-11-19 14:50 ` Mark Lord
2010-11-19 15:35 ` Mark Lord
[not found] ` <20101119141007.GB25488@infradead.org>
2010-11-19 15:37 ` Ted Ts'o
2010-11-19 15:50 ` Christoph Hellwig
[not found] ` <20101119155003.GA7145@infradead.org>
2010-11-19 16:16 ` Ted Ts'o
[not found] ` <4CE69940.6040908@teksavvy.com>
2010-11-19 15:44 ` Lukas Czerner
2010-11-19 16:30 ` Ted Ts'o
2010-11-19 22:49 ` Mark Lord
2010-11-25 2:48 ` Mark Lord
[not found] ` <4CEDCE60.9050109@teksavvy.com>
2010-11-25 4:23 ` Martin K. Petersen
2010-11-25 14:44 ` Mark Lord
2010-11-25 4:41 ` Greg Freemyer
2010-11-25 14:53 ` Mark Lord
2010-11-25 16:24 ` Greg Freemyer
2010-11-26 13:49 ` Mark Lord
2010-11-26 14:00 ` Lukas Czerner
2010-11-18 17:55 ` Chris Mason
2010-12-03 18:24 ` Ric Wheeler
2010-11-18 21:37 ` Mark Lord
2010-11-19 11:09 ` Christoph Hellwig
2010-11-19 13:54 ` Mark Lord
2010-11-19 14:40 ` Chris Mason
2010-11-19 14:53 ` Mark Lord
2010-11-19 14:57 ` Christoph Hellwig
2010-11-19 15:21 ` Mark Lord
2010-12-07 9:27 ` Christoph Hellwig
2010-12-07 16:52 ` Chris Mason
2011-06-02 4:52 ` Kyungmin Park
2011-06-02 8:14 ` Lukas Czerner
2011-06-03 2:06 ` Dave Chinner
2011-06-03 4:25 ` Kyungmin Park
2010-11-19 15:30 ` Mark Lord
2010-11-21 19:07 ` Valdis.Kletnieks
2010-11-21 20:20 ` James Bottomley
2010-11-18 14:31 ` Josef Bacik
2010-11-18 14:36 ` Tao Ma
2010-11-19 15:41 ` Ted Ts'o
2010-11-19 15:50 ` Christoph Hellwig
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=x494obe4kd5.fsf@segfault.boston.devel.redhat.com \
--to=jmoyer@redhat.com \
--cc=James.Bottomley@suse.de \
--cc=hch@infradead.org \
--cc=josef@redhat.com \
--cc=lczerner@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=sandeen@redhat.com \
--cc=tytso@mit.edu \
/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).