Post

New blog: Using Postgres pg_test_fsync tool for testing low latency writes An easy to use tool that comes with standard Postgres installation, for testing write latency of devices where you put your WAL/redo logs and any other files requiring low write latency. (link in reply)

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).

0 reposts0 likes

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.

So, "write through" is not necessarily gonna be slower, if the underlying hardware has some (battery-backed DRAM cache persistence) features in it. Enterprise storage arrays have done these kinds of tricks for decades.