A way to do atomic writes

Posted May 30, 2019 16:59 UTC (Thu) by perennialmind (guest, #45817)
Parent article: A way to do atomic writes

This is way too reminiscent of Transactional NTFS and Microsoft's earlier attempts to bring ACID guarantees to the filesystem. The generalized contract proposed makes a huge commitment and relies an awful lot on the particulars of journaling filesystems. The per-filesystem feature doesn't strike me as "kind of ugly" at all: it sounds conservative and maintainable, with reasonably predictable ramifications.

For a more general solution, I'm much more interested in that Barrier-Enabled IO Stack for Flash Storage. It just makes sense to me. It's so neat and plausible, that I can't help but wonder if it isn't also wrong. Else, I should be reading more about it on LWN. <shrug>

All I want is a sane ordering guarantee. I'm willing to accept intermediate changes being observable if it means I can have some weak, localized constraints on causality.

write(...)
write(...)
fdatabarrier(...)
rename(...)

to post comments

A way to do atomic writes

Posted Jun 2, 2019 16:55 UTC (Sun) by daniel (guest, #3181) [Link] (1 responses)

So in other words, you want exactly Tux3 semantics.

A way to do atomic writes

Posted Jun 6, 2019 14:29 UTC (Thu) by Wol (subscriber, #4433) [Link]

A synchronous flush?

Dunno how easy it would be to implement this, but imagine ...

My application (database, whatever) writes a load of stuff - a user-space journal. It then calls the flush. This triggers writing all the buffers to disk, with a guarantee that writes AFTER my sync call can be moved EARLIER in time, but ALL EARLIER writes will complete before my call returns.

That way, my application knows, when the call returns, that it's safe to start updating the files because it can recover a crash from the logs. It doesn't interfere with other applications because it's not hogging i/o. And if it's one of the few applications on an almost-single-use system then the almost continuous flushing it might trigger probably won't actually get noticed much - especially if it's a multi-threaded database because it can happily mix flushing one transaction's logs with another transaction's data.

Cheers,
Wol