Oddly enough, The SSD Guy blog has never published a post on atomic writes, even though this technique has existed for well over a decade. This post is intended to fix that.
Atomic writes are mainly designed to accelerate on-line transaction processing (OLTP) systems. This stems from the consistency needs of such systems. Every replica of the same data throughout the system must always be consistent with every other copy, consistency which must be assured even if the two copies reside in geographically dispersed areas. Data must be completely consistent: a single bit error can throw an entire accounting system into chaos.
The concern is that a multi-sector write (a “record”) may be interrupted by a disruption like a power failure, rendering its data incomplete. Without the use of special precautions, it is possible that a later read of that record might contain a mix of old and new data.
For a transaction processing system to assure data consistency, every record written to storage must be verified before that write is acknowledged by the system. This means that a record that has been written from the host’s memory to the SSD is checked to assure that the two match before that data is assumed to have been safely stored.
Before atomic writes existed, rigorous data consistency required two SSD writes and one or two reads to support these data checks. Instead of simply writing to the disk, the system performed a write, followed by a read to verify the data, then another write to the journal to signal that the new data should be accessed from the newly-written record. In certain systems this journal write was also verified by a subsequent read.
Before the journal was updated, any process that tried to read that record would be directed to the prior version.
In order to support this verification process, every SSD write consumed up to four cycles: Write, Read, Write, Read.
This was further complicated by the fact that SSDs have very slow actual writes, since the NAND flash inside the SSD has extremely slow write cycles. This means that the process had to compensate for the fact that the SSD’s internal DRAM or SRAM write buffer needed to be pushed into the SSD, which might be a very long time not only because of NAND flash’s very slow write cycles, but also because the SSD’s buffer is used to perform functions like Write Coalescing that postpone a NAND write until a suitable number of bytes has been fed into that buffer. This makes the timing of the actual write to NAND vary over a very wide range.
SSD makers decided they could accelerate this process by creating “Atomic” write operations, in which the SSD itself verifies that the entire record has been written completely and accurately. This more than doubles the throughput of the SSD over the process detailed above, while reducing wear and even latency caused by the overhead of these additional writes.
With an atomic write, the SSD verifies that the contents of the NAND fully match the SSD’s internal buffer, something that can be communicated back to the host system. It’s a relatively simple way that the SSD hardware can not only reduce the SSD’s bus traffic, but also simplify the software support required by the host system.
This feature is important in enterprise SSDs, but far less so in the client. Still, client SSDs tend to support atomicity at the sector level, where internal capacitors assure that everything in the DRAM or SRAM buffer is written into the NAND even if there is a power disruption in the middle of a write.
My company, Objective Analysis, takes great care to see that we fully understand the technologies that we analyze. If your company could benefit from the services of analysts who deeply understand both the technology and the business, please contact us to explore ways that we can help you achieve your highest level of success.