Atomic writes should be the default... ideally

Posted Feb 20, 2025 16:15 UTC (Thu) by meven-collabora (subscriber, #168883)
Parent article: Support for atomic block writes in 6.13

Any application if it has the opportunity would want to use atomic writes provided it isn't too much overhead neither too much hassle.
Like the direct I/O requirement and limited file size support of the current state.
Detecting hardware support is nicely exposed through statx already.
Hopefully this will benefit also regular user and mobile and not just database servers.

Cat pictures, and account spreadsheets are precious too.

Great work regardless.

Atomic writes should be the default... ideally

Posted Feb 20, 2025 17:36 UTC (Thu) by iabervon (subscriber, #722) [Link]

Most applications don't really want block-level atomicity properties; instead, they want whole-file atomicity, where the standard pattern is to write the new data to a new inode, and then make the filename refer to the new inode after the whole thing has been written. For a cat picture, if the file ends up containing partially old data and partially new data, it doesn't solve anything if the transitions are on block boundaries or not.

The thing that's special about databases isn't that their data is more precious, it's that small, well-defined parts of the file are being changed frequently and independently, so it's necessary to modify the stored data in place, and it's feasible and worthwhile to use a file structure where individual block changes correspond to valid files states.