SSDs with huge page sizes, small files, and wear - Page 1
Forum section: electronics / general

author: amyk
author_rank: Super Contributor
timestamp: March 22, 2025, 08:09:46 am
content: The oldest NAND flash had 512-byte pages, which corresponded with 512-byte sectors used on HDDs. Writing a sector would make the FTL program a page directly. Then came flash with 2K pages, which could store 4 sectors, but they still allowed 4 partial programs per page, so things still worked out similarly, but then newer flashes only allow a single programming operation per page, so e.g. writing a 512B sector means having to program an entire 2K/4K/8K/16K page.With this consideration in mind, are newer SSDs which use very large page sizes subjected to much more wear when used in applications that process many small files and make lots of small random writes, when compared to ones which have smaller page sizes?

author: BradC
author_rank: Super Contributor
timestamp: March 22, 2025, 08:45:42 am
content: Quote from: amyk on March 22, 2025, 08:09:46 amI haven't noticed an issue. We use an couple of SSDs in what could be seen as pathologically bad filesystem use scenarios. The streaming write of continuous files smaller than 256 bytes. It would appear the drives manage that pretty well as the write amplification doesn't seem any worse than that of the base systems.15 years ago when Intel and Sandforce reigned supreme it seemed worse.

author: golden_labels
author_rank: Super Contributor
timestamp: March 22, 2025, 01:07:33 pm
content: Page size wouldn’t be related to wear. Erase block size is. An entire block has to be erased to write even a single page to it. Historically erase block sizes were counted in mebibytes, modern SSDs use hundreds kibibytes, but still they are two order of magnitude bigger than pages.We could end at this point, but let’s continue replacing “page size” with “erase block size” in your question. Because there is one more relevant thing.Writes from applications aren’t conveyed directly to flash. The operating system buffers them for some time.(1)(2)So the SSD sees not short writes, but a contiguous write spanning multiple pages of collected data. If the data is deleted before flushing (e.g. a small temporary file lasting just seconds), it is likely it’s never even sent to the SSD.Copy-on-write file systems will not overwrite the original data, but write to a new location. Which naturally leads to high probability of small writes ending up chained together, even if their original locations were all over the place.Finally, modern SSDs do pretty good job in managing command queues and ordering write operations, further increasing the chance of related data to be written together in a single write, even if the userspace application sent the data in multiple writes.This is not bulletproof and I don’t want to tell you, that there is no negative impact. My point is, that there are multiple levels of cushioning to consider. A simplistic view will not explain the behavior here.(1)Unless the application requests flushing data to storage.(2)This is why, on Linux-based systems, writes to slow flash media exhibit the initial fast write speed that then drops abruptly, and potentially long unmounting times for those media.

author: Peabody
author_rank: Super Contributor
timestamp: March 22, 2025, 01:53:19 pm
content: Does the SSD keep track of which sectors have been written to since they were last erased? It seems it would need to do that so it could continue to write to an erased block until it is filled. Does each sector have a "dirty" bit indicating whether it is erased or has data, or something like that?

author: golden_labels
author_rank: Super Contributor
timestamp: March 22, 2025, 04:53:51 pm
content: Depends on the implementation. Many modern flash media contain logical-to-physical maps with the granularity of a single page. So pages can be mapped in a manner, that they fill up a single erase block regardless of pages’ logical addresses. However, “can” is not the same as “always do.” I can’t tell, what percentage of SSDs implement that, even if they do contain L2P maps with such granularity.