From: Theodore Tso <tytso@mit.edu>
To: "Jörn Engel" <joern@logfs.org>
Cc: Matthew Wilcox <willy@linux.intel.com>,
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 08:09:36 -0400 [thread overview]
Message-ID: <20090511120936.GB6277@mit.edu> (raw)
In-Reply-To: <20090511112729.GD29082@mit.edu>
On Mon, May 11, 2009 at 07:27:29AM -0400, Theodore Tso wrote:
>
> I believe the ATA TRIM draft standards specs don't have the 1-4
> megabyte; that craziness is only coming from the SCSI world. So we do
^^^^ I left out the worlds "granularity requirement", sorry.
> have more information than what Intel has released; also, note that
> OCZ is the first vendor who has shipped publically available SSD
> firmware with Trim support. Supposely Intel is going to try to get me
> their trim-enabled firmware under NDA, but that hasn't happened yet.
I just did a bit more web browsing, and it appears that OCZ's
userspace support for trim is currently Windows-only, and they've
implemented it by taking the filesystme off line, and running a
userspace utility that sends TRIM requests for all of the free space
on the drive.
After doing this, write speeds for sequential writes, random 512k
writes, and random 4k writes all went up by approximately 15-20% on
the OCZ Vertex, at least according to one user who did some
benchmarks. I'm not sure how repeatable that is, and how many random
writes you can do before performance levels fall back to the pre-TRIM
levels.
It's also supported only on 32-bit Windows XP. On 64-bit platforms,
there seems to be an unfortunate tendency (probability around 50%)
that the TRIM enablement software trashes the data stored on the SSD.
So there is currently a warning on the OCZ discussion web forum that
the tools should only be used on 32-bit Windows platforms.
All of the web browsing I've doen confirms that the ATA folks expect
trim to work on 512-sector granularity. It's only the lazy b*stards
who don't want to change how their large high-end storage boxes work
that are trying to push for 1-4 megabyte alignment and granularity
requirements in the SCSI standards. I'm not that worred about the
crappy flash devices (mostly SD and Compact flash devices, not SSD's)
that don't do sub-erase block wear-leveling and management; those will
probably get weeded out of the market pretty quickly, since SSD's that
crappy will have really lousy small random write performance as well,
and web sites like Anandtech and PC Perspectives have picked up on why
that really hurts your OS performance on said crappy SSD's.
- Ted
next prev parent reply other threads:[~2009-05-11 12:10 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 [this message]
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
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=20090511120936.GB6277@mit.edu \
--to=tytso@mit.edu \
--cc=jens.axboe@oracle.com \
--cc=joern@logfs.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=rwheeler@redhat.com \
--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 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.