Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Write to SSDs [pdf]

vldb.org

Post reply on HN
Print view View original

31–37 of 37 posts

Re: How to Write to SSDs [pdf]

#31

Post by UltraSane »

lia323 wrote: post #30
UltraSane wrote: post #29

Earlier quoted context omitted.

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 e…

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

Re: How to Write to SSDs [pdf]

#32

Post by pgaddict »

Interesting paper. I only started reading / digesting it, but:

- I'm not sure how to interpret the Figure 1. It says "Flash writes (KB) per page", but it doesn't really say which page sizes were used. AFAIK MySQL has 16K by default, PostgreSQL has 8K, LeanStore has 4K, but that which makes the numbers a bit hard to compare.

- Likewise, I'm a bit unsure about the doublewrite buffering in Postgres, described as "indirect". Postgres doesn't really do doublewrite (we really should, I think), we write pages to WAL and then to data files. I assume that's what is meant by "indirect" in the paper. But this very much depends on the checkpoint frequency and write pattern, as the FPI is written only for the first page change. I wonder if the results in the paper consider this. Maybe the workload is such that it always hits the page just once between checkpoints (i.e. a worst case). Also, the WAL part is nicely sequential, which should play nice with SSDs.

Re: How to Write to SSDs [pdf]

#33

Post by lia323 »

pgaddict wrote: post #32

Interesting paper. I only started reading / digesting it, but: - I'm not sure how to interpret the Figure 1. It says "Flash writes (KB) per page", but it doesn't really say which page sizes were used. AFAIK MySQL has 16K by default, PostgreSQL has 8K, LeanStore has 4K, but that which makes the numbers a bit hard to compare. - Likewise, I'm a bit unsure about the doublewrite buffering in Postgres, described as "indire…

Thanks!

The caption of Figure 1 lists the page size used by each system (i.e., the default configuration).

We use different page sizes across systems, and as you said, it is a bit difficult to compare them directly apples-to-apples. This is actually intentional! Because this also exposes the B-tree index-level write amplification effects. In that sense, Figure 1 kind of suggests that larger page sizes may not necessarily be great for write amplification.

And yes, you are correct regarding Postgres. Instead of having a separate doublewrite buffer file, Postgres relies on WAL full-page writes, which indirectly trigger additional checkpoint writes, so the effect is not entirely straightforward to quantify. To explain that, we discuss how we measured DB WAF for Postgres in Section 10.7 (“How can we calculate DB WAF on other DBMSs?”) of the appendix version: https://arxiv.org/pdf/2603.09927

Regarding the WAL part, yes, the WAL itself is nicely sequential and should generally behave well on SSDs. But once it gets mixed with small random writes that are eventually persisted to flash, it will unfortunately still likely suffer from SSD WAF.

Re: How to Write to SSDs [pdf]

#34

Post by lia323 »

UltraSane wrote: post #31
lia323 wrote: post #30

Earlier quoted context omitted.

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 e…

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

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

Re: How to Write to SSDs [pdf]

#35

Post by [deleted] »

pgaddict wrote: post #32

Interesting paper. I only started reading / digesting it, but: - I'm not sure how to interpret the Figure 1. It says "Flash writes (KB) per page", but it doesn't really say which page sizes were used. AFAIK MySQL has 16K by default, PostgreSQL has 8K, LeanStore has 4K, but that which makes the numbers a bit hard to compare. - Likewise, I'm a bit unsure about the doublewrite buffering in Postgres, described as "indire…

[deleted]

Re: How to Write to SSDs [pdf]

#36

Post by geertj »

jauntywundrkind wrote: post #25
geertj wrote: post #16

Earlier quoted context omitted.

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)

To be clear, I was asking from a personal perspective, unrelated to my role at Google.

Re: How to Write to SSDs [pdf]

#37

Post by eekdrnf9904 »

lia323 wrote: post #9

Hi, I’m the first author of the paper. Thanks for the interest and the kind comments. The extended version is available on arXiv if you’d like more details: https://arxiv.org/pdf/2603.09927 The appendix includes additional details and FAQ-style answers that did not fit into the VLDB version.

Amazing Paper!
Post reply on HN