3 ms·
> Instead of writing every single change to the SSD immediately, we can instead queue many such writes and persist the whole queue in one go. Instead of having
by cogman10 2y ago
> Instead of writing every single change to the SSD immediately, we can instead queue many such writes and persist the whole queue in one go. Instead of having one latency-sensitive round trip per commit, we now have one round trip per queue flush, let’s say every 100 commits. We just have to be careful not to tell the user that their data has been committed before the queue containing their data has been flushed.
I'm a little bit unclear, is the suggested method here issuing 100 `write` commands and then a `sync` (or something similar) and only informing the downstream of success when the `sync` is finish? Or is the DB actually maintaining a queue of commits to be written that get fsynced all at once?
- Dalewyn 2y agoCPU: "Hey SSD, I need to write 100MB of data." SSD Controller: "Okay, go for it." CPU: <Intense Writing Noises /> SSD Controller: "(Hey OS, can you dump what the CPU's throwing at me in your RAM instead? Don't tell him.)" OS: "Okay." <100MBs later /> CPU: "All done! You got it, SSD?" SSD Controller: "Uhh, yeah, one sec." SSD Controller: "(Hey OS, throw me all that data before the CPU gets wind of this.)" OS: "Okay." OS: <Intense Writing Noise /> SSD Controller: "Alright, come on finish writing ya damn NAND." NAND: "Hold on, man." CPU: "Sitrep, SSD?" SSD Controller: "Almost done!" SSD Controller: "All done!" CPU: "Great!" --- Long story short, big bursty writes are faster than small intermittent writes and SSD controllers are bloody liars.