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: <20090511133947.GE8112@parisc-linux.org>
Date:	Mon, 11 May 2009 07:39:48 -0600
From:	Matthew Wilcox <matthew@....cx>
To:	Greg Freemyer <greg.freemyer@...il.com>
Cc:	Theodore Tso <tytso@....edu>, 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.  For some reason, I thought their was
> only one mapping per erase block and within the erase block the
> sectors were contiguous..

I believe there is a mapping per LBA, not per erase block.  Of course,
different technologies will have different limitations here, but it
would be foolish to assume anything about SSDs at this point.

(For those who haven't heard my disclaimer before, the Intel SSD team
don't tell me anything fun about how the drives work internally).

-- 
Matthew Wilcox				Intel Open Source Technology Centre
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
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