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: <20090511124325.GC6585@logfs.org>
Date:	Mon, 11 May 2009 14:43:25 +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 07:27:29 -0400, Theodore Tso wrote:
> 
> I can't fix hardware braindamage.  Given that the standard
> specifications is terminally broken, (and we can't really fix it
> without getting the drive manufacturers to rip out and replace NCQ
> with something sane --- good luck with that) the complexity is pretty
> much unaviodable.  Still think my proposal is ludicrous?

Given the hardware braindamage it is relatively sane.  As always, it
would be much better to fix the problem and not add workarounds, but we
seem to lack the gods favor this time around.

Can't anyone explain to the SATA folks that a discard is much closer to
a write than to a secure erase or some other rare and slow command?

Jörn

-- 
Mundie uses a textbook tactic of manipulation: start with some
reasonable talk, and lead the audience to an unreasonable conclusion.
-- Bruce Perens
--
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