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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20090511142740.GC6277@mit.edu>
Date:	Mon, 11 May 2009 10:27:40 -0400
From:	Theodore Tso <tytso@....edu>
To:	Greg Freemyer <greg.freemyer@...il.com>
Cc:	Jörn Engel <joern@...fs.org>,
	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,
	Linux RAID <linux-raid@...r.kernel.org>
Subject: Re: Is TRIM/DISCARD going to be a performance problem?

On Mon, May 11, 2009 at 09:10:15AM -0400, Greg Freemyer wrote:
> 
> That implies that the SSD folks are not treating erase blocks as a
> contiguous group of sectors.  

Correct. 

> For some reason, I thought their was
> only one mapping per erase block and within the erase block the
> sectors were contiguous..

No, if you try to treat erase blocks as a contiguous group of
sectors, you'll have terrible write amplification problems (leading to
premature death of the SSD) and terrible small random write
performance.  Flash devices optimized for digital cameras might have
done that, but for SSD's, this will result in catastrophically bad
performance, and very limited lifespan.  As I said, I expect these
SSD's to be weeded out of the market very shortly.

For any sane implementation of an SSD, the mapping will be on a per
LBA basis, not on a per-erase block basis.

> More realistic is to figure out a way to make it deterministic at
> least for the short term (by writing data to all the trimmed blocks?),
> then reshaping, then having a tool to scan the filesystem and re-issue
> all the trim commands.

Writing data to all of the trimmed block?  Um, no.  That would be a
diaster, since it accelerates the wear and tear of the SSD.  The whole
*point* of the TRIM command is to avoid needing to do that.

The whole worry about determinism is highly overrated.  If the
filesystem doesn't need a block, then it doesn't need it.  What you
read after you send a TRIM command, whether it is the old data because
the device applied some kind of rounding, or random data, or all
zero's, won't matter to the filesystem.  Why should the filesystem
care?  I know I certainly don't....

					- 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