Post

Thank you for the blog. But are you sure about write through vs write back? In my experience (and I just checked with Google) write back mode is the one where disk acknowledges the write once data is in the cache. And write through is slower because data has to be written to the actual disk.

Oh, good detail to bring out: Indeed "write back" means that the write is not persistent when it's acknowledged and you need an explicit request with REQ_OP_FLUSH or FUA flag to direct the controller to persist it. BUT, if you have a reliable write cache, then... (continued)

... then the SSD device can present itself as "write through", even if it actually keeps the write payload in DRAM cache for a while (but has power-loss-protection, so effectively your cached writes will land in persistent storage on power failure).

And if you look into another device listed in my blog entry (INTEL SSDPED1D280GA), that's an Intel Optane SSD that doesn't even have a DRAM cache as writes always go to the low-latency 3D XPoint "NAND", so it can advertise that it doesn't need additional "flush" requests to persist data sent to it.

tanelpoder.comUsing Postgres pg_test_fsync tool for testing low latency writes - Tanel Poder ConsultingHere’s a useful tool for quickly testing whether a disk (or a cloud block store volume) is a good candidate for your database WAL/redo logs and any other files that require low latency writes. T...

Link to post here: tanelpoder.com/posts/using-...

Gunnar Morling

@gunnarmorling.dev

Nice write-up, didn't know about that tool! One question on the lower latency of the enterprise grade disk with the powered DRAM cache: wouldn't you be back to the (slower) NAND speed for sustained writes exceeding the buffer size?

The controller can bundle up a bunch of cached writes and format a new NAND block with these writes (and adjust the flash-translation-layer metadata accordingly). So you'd get closer to "perfect NAND writes" just like you'd get with append-only LSM trees etc.