[lia323]

All experiments in the paper were done using enterprise SSDs. Large write buffers inside the SSD can definitely help mask the performance degradation of slow flash writes by absorbing and consolidating updates before flushing to flash, but they do not fundamentally solve write amplification itself.

Unless the write access pattern repeatedly hits the internal write buffer such that many updates are absorbed before they ever need to be persisted to flash.

[UltraSane]

In enterprise storage systems the NVRAM write buffer is centrally located in the controllers and the proprietary filesystem is designed to use it. This means SSDs very rarely have to handle small writes.

[lia323]

If you are referring to controller-side NVRAM that sits before the SSDs at a higher layer, then yes, you are right that small writes can often be absorbed and consolidated there before reaching flash. Enterprise SSDs themselves seem to employ internal write buffering for a similar purpose, as I mentioned before. However, this still does not fundamentally eliminate GC-induced SSD write amplification once the data is eventually persisted to flash.

I assume NVRAM buffering at that layer will definitely make the write access pattern less skewed from the SSD’s point of view and can therefore reduce WAF. We did not evaluate that kind of storage-stack setup in the paper, though.

[UltraSane]

Enterprise storage designs are actually really interesting and varied. Two of the most interesting are VAST Data which was designed specifically for QLC flash and Infinidat which uses 3 controllers and 3TB of RAM for cache

[lia323]

wow, 3 controllers and 3TB of RAM for cache is pretty wild. I wasn't aware of that design before. Thanks for sharing!