linux-ext4 - Re: Is TRIM/DISCARD going to be a performance problem?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 11 May 2009 08:09:36 -0400
From:	Theodore Tso <tytso@....edu>
To:	Jörn Engel <joern@...fs.org>
Cc:	Matthew Wilcox <willy@...ux.intel.com>,
	Jens Axboe <jens.axboe@...cle.com>,
	Ric Wheeler <rwheeler@...hat.com>,
	linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org
Subject: Re: Is TRIM/DISCARD going to be a performance problem?

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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html