Path: ...!news-out.netnews.com!netnews.com!s1-4.netnews.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!nntp.club.cc.cmu.edu!weretis.net!feeder9.news.weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Stefan Monnier <monnier@iro.umontreal.ca>
Newsgroups: comp.arch
Subject: SSDs (was: Another security vulnerability)
Date: Tue, 11 Jun 2024 16:20:59 -0400
Organization: A noiseless patient Spider
Lines: 23
Message-ID: <jwv1q53gsu6.fsf-monnier+comp.arch@gnu.org>
References: <utpoi2$b6to$1@dont-email.me> <utr63b$u40q$1@dont-email.me>
	<2024Mar25.093751@mips.complang.tuwien.ac.at>
	<8biMN.162475$46Te.1680@fx38.iad> <uttc4e$1elji$2@dont-email.me>
	<ZIAMN.122729$SyNd.55207@fx33.iad>
	<2024Mar26.173626@mips.complang.tuwien.ac.at>
	<5811929d48fa825289f362918b74b386@www.novabbs.org>
	<2024Jun5.103859@mips.complang.tuwien.ac.at>
	<f9496dc0d3398b24b9ea1912cb060283@www.novabbs.org>
	<v47v5b$lmqu$1@dont-email.me>
	<0718f44428fe0d519d89e056ac46b016@www.novabbs.org>
	<v48jtf$srn2$1@dont-email.me> <v49617$102nd$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Tue, 11 Jun 2024 22:21:10 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="adecb8f45b089a8dec176645b14c32be";
	logging-data="1296145"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18v6jxHAiUcAExQ7YeUcV6XwPk+Dh4TFHo="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:l6Upe8PDiATrw7zuRsxJTiHxf20=
	sha1:6XjQFW1fb/3IPOAp+UbUrJzELzI=
X-Received-Bytes: 2659
Bytes: 2841

> It has to have a substantial amount of RAM in order to coalesce writes,
> after applying all those remapping/wear leveling layers. This write-back
> cache has a limited amount of dirty buffers, preferably low enough that they
> can all be flushed to persistent storage in case of power loss.

IIUC some don't have much RAM to speak of (they probably have some
on-CPU cache-size RAM, of course) and lend some DRAM from the host system
instead (accessed over PCI).  The technique is called HMB (Host Memory
Buffer), and it's apparently quite popular.
According to https://journals.plos.org/plosone/article?id=10.1371%2Fjournal.pone.0229645
the HMB is used mostly for the remapping table, while the write buffer
used for coalescing is presumably some STL flash.

> The main task however is that when first turned on, the CPU will run
> a substantial amount of burn-in testing, and then decide how many flash
> pages are actually usable.

IIUC, another time-consuming task at startup can be to find the location
of the logical->physical mapping table (since it can't be written at
a fixed place in the flash, for wear-leveling reasons).


        Stefan