3 ms·

The concerns in the paper motivating the locality rule really only apply to low-end consumer SSDs. Enterprise/datacenter SSDs and high-end consumer SSDs all car

The concerns in the paper motivating the locality rule really only apply to low-end consumer SSDs. Enterprise/datacenter SSDs and high-end consumer SSDs all carry plenty of DRAM for the FTL, so they don't suffer as much penalty for poor locality and it's really only worth drawing a distinction between sequential and non-sequential access. I also don't think it's common for SSDs to use the kind of hybrid page/block mapping FTL that the Aligned Sequentiality rule is about. These days, if you want a SSD that cuts down on DRAM costs, you want the NVMe Zoned Namespaces feature. The problems that the Uniform Lifetime rule and Grouping By Death Time rule are concerned with can be handled explicitly with features like NVMe's Streams directives, or Zoned Namespaces. Overall, this article doesn't seem to have aged particularly well, and I'm not sure it was that useful and relevant even in 2017.

mjevans 5y ago
At the application level (E.G. a database storage layout) even for zoned namespaces the GENERALIZED principles seem logical. Even in the old days for tiny 512 byte sectors the seek and re-write time for a partial update likely influenced designs. Today I consider myself lucky to get storage with 4K sectors and I recall seeing rumors that game console SSDs would ship with far larger erase blocks. I would prefer all storage came with interfaces and common access protocols for utilizing the raw features of the device directly. An enumerate of raw permanent storage addresses (possibly read only, write only in one packet, or write via write-zone promotion), (readable?) write buffer locations which can be promoted to long term storage, etc. That might be NMVe 'streams', which I haven't read about yet. A quick search result makes me think they might be close and could have evolved there, but weren't there 2 years ago. https://www.anandtech.com/show/14543/nvme-14-specification-published https://www.anandtech.com/show/14543/nvme-14-specification-p...
- wtallis 5y ago
  > Today I consider myself lucky to get storage with 4K sectors and I recall seeing rumors that game console SSDs would ship with far larger erase blocks. The erase blocks on current NAND flash are already up to 16+MB, while the page sizes are typically 16kB. So even presenting the illusion of 4kB sectors requires a lot of extra background work from the SSD controller, and that's been true for generations. Also, the NVMe Streams feature is from the 1.3 spec in 2017: https://www.anandtech.com/show/11436/nvme-13-specification-published-new-features https://www.anandtech.com/show/11436/nvme-13-specification-p... Like most of the more advanced NVMe features, it's targeted at enterprise or datacenter use cases and most of the initial adoption is among the hyperscale cloud providers that have the resources and incentive to optimize their IO stack from top to bottom.
dan-robertson 5y ago
The paper has other locality concerns which apply to all SSDs: “Locality is not only valuable for reducing required RAM for translations, but also for other purposes. For example, all types of SSDs are sensitive to locality due to their data cache. In addition, for SSDs that arrange flash chips in a RAID-like fashion, writes with good locality are more likely to update the same stripe and the parity calculation can thus be batched and written concurrently [92], improving performance.”
- wtallis 5y ago
  SSDs don't have much data caching. They use the large amount of DRAM for metadata (the FTL), and have small amounts of write buffering. Read caching and prefetching tends to be minimal and amount to the page buffers on each plane of each die, ie. the hardware has to perform a read of 16kB even if you only ask for 4kB. The bit about updating the same stripe also sounds like hard drive talk, where data can be updated in-place. It doesn't make sense in an SSD context where all modifications go to new stripes and the drive will readily combine a batch of writes to disparate LBAs into a burst of writes to contiguous physical pages. There's just not much truth behind the Locality rule that isn't already covered by the Request Scale rule.

mjevans 5y ago

At the application level (E.G. a database storage layout) even for zoned namespaces the GENERALIZED principles seem logical. Even in the old days for tiny 512 byte sectors the seek and re-write time for a partial update likely influenced designs. Today I consider myself lucky to get storage with 4K sectors and I recall seeing rumors that game console SSDs would ship with far larger erase blocks. I would prefer all storage came with interfaces and common access protocols for utilizing the raw features of the device directly. An enumerate of raw permanent storage addresses (possibly read only, write only in one packet, or write via write-zone promotion), (readable?) write buffer locations which can be promoted to long term storage, etc. That might be NMVe 'streams', which I haven't read about yet. A quick search result makes me think they might be close and could have evolved there, but weren't there 2 years ago. https://www.anandtech.com/show/14543/nvme-14-specification-published https://www.anandtech.com/show/14543/nvme-14-specification-p...

wtallis 5y ago
> Today I consider myself lucky to get storage with 4K sectors and I recall seeing rumors that game console SSDs would ship with far larger erase blocks. The erase blocks on current NAND flash are already up to 16+MB, while the page sizes are typically 16kB. So even presenting the illusion of 4kB sectors requires a lot of extra background work from the SSD controller, and that's been true for generations. Also, the NVMe Streams feature is from the 1.3 spec in 2017: https://www.anandtech.com/show/11436/nvme-13-specification-published-new-features https://www.anandtech.com/show/11436/nvme-13-specification-p... Like most of the more advanced NVMe features, it's targeted at enterprise or datacenter use cases and most of the initial adoption is among the hyperscale cloud providers that have the resources and incentive to optimize their IO stack from top to bottom.

dan-robertson 5y ago

The paper has other locality concerns which apply to all SSDs: “Locality is not only valuable for reducing required RAM for translations, but also for other purposes. For example, all types of SSDs are sensitive to locality due to their data cache. In addition, for SSDs that arrange flash chips in a RAID-like fashion, writes with good locality are more likely to update the same stripe and the parity calculation can thus be batched and written concurrently [92], improving performance.”

wtallis 5y ago
SSDs don't have much data caching. They use the large amount of DRAM for metadata (the FTL), and have small amounts of write buffering. Read caching and prefetching tends to be minimal and amount to the page buffers on each plane of each die, ie. the hardware has to perform a read of 16kB even if you only ask for 4kB. The bit about updating the same stripe also sounds like hard drive talk, where data can be updated in-place. It doesn't make sense in an SSD context where all modifications go to new stripes and the drive will readily combine a batch of writes to disparate LBAs into a burst of writes to contiguous physical pages. There's just not much truth behind the Locality rule that isn't already covered by the Request Scale rule.