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: <20090511100624.GB6585@logfs.org>
Date:	Mon, 11 May 2009 12:06:24 +0200
From:	Jörn Engel <joern@...fs.org>
To:	Theodore Tso <tytso@....edu>
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, 11 May 2009 04:37:54 -0400, Theodore Tso wrote:
> 
> Well, no one has actually implemented the low-level TRIM support yet;

Iirc dwmw2 did so for some of the FTL drivers.  More a curiosity than a
useful device, though.

> Well, no, Matthew's changes didn't do any of that, I suspect because
> most SSD's, including X25-M, are expected to have a granularity size
> of 1 block.  It's the crazy people in the SCSI standards world who've
> been pushing for granlarity sizes in the 1-4 megabyte range; as I
> understand things, the granularity issue was not going to be a problem
> for the ATA TRIM command.

I am not sure about this part.  So far Intel has been the only party to
release any information about their dark-grey box.  All other boxes are
still solid black.  And until I'm told otherwise I'd consider them to be
stupid devices that use erase block size as trim granularity.

Given the total lack of information, your guess is as good as mine,
though.

> As far as thinking that the proposal is ludicrous --- what precisely
> did you find ludicrous about it?

Mainly the idea that discard requests should act as barriers and instead
of fixing that, you propose a lot of complexity to work around it.

> The only problem with SSD's is the people who designed the ATA TRIM
> command requires us to completely drian the I/O queue before issuing
> it.  Because of this incompetence, we need to be a bit more careful
> about how we issue them.

And this bit that I wasn't aware of.  Such a requirement in the standard
is a trainwreck indeed.

Jörn

-- 
Victory in war is not repetitious.
-- Sun Tzu
--
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