Support for atomic block I/O operations [LWN.net]

By Jonathan Corbet
November 6, 2013

Some newer storage devices have the ability to perform atomic I/O operations. An atomic operation will either succeed or fail as a unit; if multiple blocks are to be written, they will all make it to persistent storage or none will. This feature has the potential to improve life considerably at the higher levels, but the kernel currently has no way to support it.

Chris Mason's atomic I/O patch set aims to fix that situation. It allows a file to be opened with the O_ATOMIC and O_DIRECT flags (only direct I/O is supported) to request atomic semantics. Thereafter, every write() call will be executed atomically if the hardware supports it. This feature is, thus, quite easy to use from user space.

Within the kernel, there is a new function available to block drivers:

    void blk_queue_set_atomic_write(struct request_queue *q,
    				    unsigned int segments);

This function tells the block layer that the device behind the given request queue can perform atomic operations up to the given number of segments (separate ranges of blocks on the storage medium). Thereafter, I/O requests may arrive with the REQ_ATOMIC flag set to request atomic execution. The block layer will ensure that the maximum segment count is not exceeded.

One can imagine a number of uses for this functionality. A journaling filesystem could, for example, use it to write out the journal and the commit block together, knowing that said commit block will only be visible if everything else was successfully written. But, Chris says, the first target is MySQL:

O_ATOMIC | O_DIRECT allows mysql and friends to disable double buffering. This cuts their write IO in half, making them roughly 2x more flash friendly.

The patch set (which does not add support to any block drivers) is relatively small and simple, so it should have a relatively good chance of being merged in the very near future.

Index entries for this article
Kernel	Atomic I/O operations
Kernel	Block layer/Atomic operations

to post comments

Support for atomic block I/O operations

Posted Nov 8, 2013 21:38 UTC (Fri) by pr1268 (guest, #24648) [Link] (1 responses)

It allows a file to be opened with the O_ATOMIC and O_DIRECT flags (only direct I/O is supported) to request atomic semantics.

Wouldn't opening a file with the O_ATOMIC flag automatically imply O_DIRECT? (That's how I understand it, based on the clause inside the parentheses.) Or, would one have to explicitly specify both flags? What would happen if someone opened a file O_ATOMIC but without O_DIRECT?

Support for atomic block I/O operations

Posted Nov 14, 2013 6:24 UTC (Thu) by shykta (guest, #94007) [Link]

Given the O_TMPFILE story, I'd hope *one* of those combinations fails when the flag isn't understood. (Or maybe O_ATOMIC without O_DIRECT should fail if O_ATOMIC *is* understood - just so it can be tested for).

Otherwise, userspace will be assuming the kernel is providing safety guarantees that may not really be there...

Support for atomic block I/O operations

Posted Dec 27, 2013 10:39 UTC (Fri) by lpremoli (guest, #94065) [Link]

IMHO this feature can only be regarded as Flash Friendly if the eatomic contents are really big. Otherwise you fall back into the REQ_FUA + REQ_FLUSH use case with little or no room for optimization.