Sujet : SSDs (was: Another security vulnerability)
De : monnier (at) *nospam* iro.umontreal.ca (Stefan Monnier)
Groupes : comp.archDate : 11. Jun 2024, 21:20:59
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <jwv1q53gsu6.fsf-monnier+comp.arch@gnu.org>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14
User-Agent : Gnus/5.13 (Gnus v5.13)
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.0229645the 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