Shouldn't the required cache size be dependent on throughput more so than disk size? It does not necessarily seem like you'd need a bigger write cache if the disk is bigger, people who have a 2TB drive don't read/write 2x as much in a given time as those with a 1TB drive. Or am I missing something?
IIRC SSD manufacturers are likely to store a mapping table of LBAs (logical block addresses) to PBAs (physical block addresses) in the DRAM or Host Memory Buffer.
Some calculation like:
total storage size / page size per LBA (512B or 4KiB usually) * mapping data structure size
> SSD manufacturers are likely to store a mapping table of LBAs (logical block addresses) to PBAs (physical block addresses) in the DRAM or Host Memory Buffer.
Are LBA's a thing on SSD's nowadays? I thought it was the legacy of the spinning rust.
SSD's operate on memory pages of the flash memory, and the page management is a complicated affair that is also entirely opaque to the host operating system due to the behind the scenes page remapping. Since flash memory is less durable (in the long term), the SSD's come overprovisioned and the true SSD capacity is always more (up to a double if my memory serves me well). The SSD controller also runs an embedded RTOS that monitors failures in flash chips and proactively evacuates and remaps ailing flash memory pages onto the healthy ones. Owing to this behaviour, the memory pages that the SSD controller reports back to the operating system have another, entirely hidden, layer of indirection.
Yep, LBAs are the primary addressing scheme in the NVMe spec, written into every single IO command. I would imagine there could be a better way, but NVMe & OS support still carries some baggage from SATA HDDs -> SATA SSDs -> NVMe SSDs.
As you mentioned, over-provisioning and other NAND flash memory health management techniques like garbage collection and wear leveling are needed for usable modern SSDs. Modern SSD controllers are complex beasts having 3-7 microprocessor cores (probably double digit core counts now with PCIe 5.0), encryption engines, power & thermal management, error correction, multiple hardware PHYs, etc.
