[flagged]
How to Write to SSDs [pdf]
21–30 of 37 posts
Re: How to Write to SSDs [pdf]
#22[deleted]
Re: How to Write to SSDs [pdf]
#23> we introduce a NoWA (No Write Amplification) pattern that guarantees SSD WAF = 1, even at full device utilization. That they got this to work on regular commodity SSDs (from multiple vendors) is very impressive.
Very interesting indeed. They mention a very simple rule of thumb (not new to this work AIUI but still worthwhile) that suggests arranging data into blocks that will all be discarded in bulk at the same time. Doing this is generally already enough to make a dent into write-amplification.
Re: How to Write to SSDs [pdf]
#24Enterprise storage systems solve this problem by having writes go to 8GB or more of NVRAM and then get consolidated and flushed to the SSDs. I wish consumer grade systems used a similar system.
Re: How to Write to SSDs [pdf]
#25Earlier quoted context omitted.
The zoned-storage people (whom shingled folks were a subsect of) seemed pretty ok with the FDP (Flexible Data Placement - TP4146b) scheme that finally finally finally got hammered out for NVMe 2.1 (August 2024). It was also designed to satisfy the open-channel flash people as well. It's a fairly simple concept that lets you have some write-affinity, that lets you declare when writing that this write should be associa…
Speaking of zoned SSDs (ZNS or FDP), are any of these available today without having to ‘call sales’? I wanted to experiment with this maybe 2 years back and there was nothing.
With apologies for outing your bio here so pointedly,
> Storage nerd @ Google
Vendors, are you listening?
(And the software would/could be so much better... If this were available to play with)
Re: How to Write to SSDs [pdf]
#26SMR Hard Drives have very different rules about how you should access them vs conventional hard drives or SSDs. I wonder how much optimizing for SMR drives (Big sequential writes) would also optimize for other drive types.
SMR drives shouldn't be used with write heavy databases. Or really any write heavy workload. They are best used for storing lots of read only.
Re: How to Write to SSDs [pdf]
#27Enterprise storage systems solve this problem by having writes go to 8GB or more of NVRAM and then get consolidated and flushed to the SSDs. I wish consumer grade systems used a similar system.
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.
Re: How to Write to SSDs [pdf]
#28> we introduce a NoWA (No Write Amplification) pattern that guarantees SSD WAF = 1, even at full device utilization. That they got this to work on regular commodity SSDs (from multiple vendors) is very impressive.
Very interesting indeed. They mention a very simple rule of thumb (not new to this work AIUI but still worthwhile) that suggests arranging data into blocks that will all be discarded in bulk at the same time. Doing this is generally already enough to make a dent into write-amplification.
The end goal of the NoWA write pattern is conceptually similar to what you described, in the sense that NoWA tries to increase the chance that data becomes invalid together inside the SSD, which is also what mechanisms such as TRIM try to facilitate.
The NoWA pattern is more about proactively aligning the application-level GC behavior with the SSD’s internal GC behavior, such that the SSD has little or no valid-page movement left to do internally.
Re: How to Write to SSDs [pdf]
#29Enterprise storage systems solve this problem by having writes go to 8GB or more of NVRAM and then get consolidated and flushed to the SSDs. I wish consumer grade systems used a similar system.
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 the…
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.
Re: How to Write to SSDs [pdf]
#30Earlier quoted context omitted.
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 the…
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.
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.