linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Theodore Y. Ts'o" <tytso@mit.edu>
To: Adrian Hunter <adrian.hunter@intel.com>
Cc: Christoph Hellwig <hch@lst.de>, Faiz Abbas <faiz_abbas@ti.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-omap <linux-omap@vger.kernel.org>,
	linux-mmc <linux-mmc@vger.kernel.org>,
	linux-block <linux-block@vger.kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Jens Axboe <axboe@kernel.dk>,
	linux-ext4@vger.kernel.org
Subject: Re: mmc filesystem performance decreased on the first write after filesystem creation
Date: Wed, 30 May 2018 12:15:07 -0400	[thread overview]
Message-ID: <20180530161507.GA14279@thunk.org> (raw)
In-Reply-To: <43d4164f-5dda-b49a-6008-1f5bf4b08547@intel.com>

On Wed, May 30, 2018 at 11:51:41AM +0300, Adrian Hunter wrote:
> 
> And discards are not enabled by default by mount so, at least on ext4,
> adding "-o discard" is needed in the mount options.

This is because doing discards right away is not always a win from
performance reasons.  There are some flash devices where discards are
super-slow and some devices where issuing discards too quickly would
cause them to trigger internal FTL race conditions and turn them into
paperweights.

There was at least one engineer from a Linux distribution who argued
for making discard not the default because back then, there were a lot
of SSD's floating out there (by a manufacturer who thankfully has
since gone bankrupt :-) for which they didn't want to deal with the
support requests from people who were angry about lost data or
destroyed SSD's --- because guess who they would blame?

Also, please note that for many devices it's much better to
periodically run fstrim (once a day or once a week) out of cron.

If someone wants to do a survey of available hardware and demonstrate:

   * there is significant value from enabling -o discard by default
     (instead of using fstrim)

   * there are no (or at least very, very few) devices for which
     enabling -o discard results in a major performance regression,
     and

   * if there are any devices left that turn into paperweights, they can
     be managed using blacklists,

I'm certainly open to changing the default.  There was, however, a
really good *reason* why the default was chosen to be the way it is.

					- Ted

      reply	other threads:[~2018-05-30 16:15 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <a976e20a-3ed1-43d0-4665-f570ef496d02@ti.com>
2018-05-28  6:26 ` mmc filesystem performance decreased on the first write after filesystem creation Christoph Hellwig
2018-05-30  8:44   ` Adrian Hunter
2018-05-30  8:51     ` Adrian Hunter
2018-05-30 16:15       ` Theodore Y. Ts'o [this message]

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=20180530161507.GA14279@thunk.org \
    --to=tytso@mit.edu \
    --cc=adrian.hunter@intel.com \
    --cc=axboe@kernel.dk \
    --cc=faiz_abbas@ti.com \
    --cc=hch@lst.de \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=ulf.hansson@linaro.org \
    /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).