3 ms·

I think we have a quiproquo about the level of atomicity here. You seem to be talking about _application level_ atomicity, like when you issue 4 write() to a f

I think we have a quiproquo about the level of atomicity here. You seem to be talking about _application level_ atomicity, like when you issue 4 write() to a file and want an "all or nothing" flush of these 4 writes. I'm talking about OS level atomicity, as in "I want a write() (or fsync) to block until it is flushed to disk". Am I understanding correctly?

josephg 3y ago
Atomicity means something either happens entirely or it doesn't happen at all. > I'm talking about OS level atomicity, as in "I want a write() (or fsync) to block until it is flushed to disk". Thats not atomicity. Thats a blocking API. And we already have an fsync that does that. Blocking and atomicity are unrelated properties. You could have a blocking write thats not atomic (so if your computer turns off halfway through the write, it might have only half completed). And you can have an atomic write thats non-blocking (async). Or both or neither.
- Galanwe 3y ago
  > Thats not atomicity. Thats a blocking API. > Blocking and atomicity are unrelated It's the same in this context. fsync uses a blocking API to implement atomicity. That is, after an fsync() all previous writes should have been written. > we already have an fsync that does that. Did you actually read the article...? The whole thing is about the fact that disk controllers can eagerly notify that a write was flushed to disk while in fact it is still in the disk write cache, and could have been either partially, fully or partly written, thus tricking fsync().
  - josephg 3y ago
    > It's the same in this context. fsync uses a blocking API to implement atomicity No, it doesn’t. In that context fsync is a write barrier. It doesn’t make writes atomic. The difference is this: If you issue a handful of writes then your computer crashes, some, all or none of the writes may have completed. And some writes might be “skewed” - where part of the write succeeded and part did not. Atomicity means a set of actions happens as one indivisible unit, and it either all happens or all doesn’t happen. Think database transactions. Filesystem writes are not like that. They are not atomic operations[1]. Fsync does not change the behaviour of the write system call. Fsync only stalls your program until all writes have been written to disk, at least assuming your drive isn’t lying to you. Just like a memory barrier. If your computer crashes before fsync returns, all bets are off. [1] With the exception of aligned writes under the device block size. Allegedly. I’d still like to see this actually documented somewhere.

josephg 3y ago

Atomicity means something either happens entirely or it doesn't happen at all. > I'm talking about OS level atomicity, as in "I want a write() (or fsync) to block until it is flushed to disk". Thats not atomicity. Thats a blocking API. And we already have an fsync that does that. Blocking and atomicity are unrelated properties. You could have a blocking write thats not atomic (so if your computer turns off halfway through the write, it might have only half completed). And you can have an atomic write thats non-blocking (async). Or both or neither.

Galanwe 3y ago
> Thats not atomicity. Thats a blocking API. > Blocking and atomicity are unrelated It's the same in this context. fsync uses a blocking API to implement atomicity. That is, after an fsync() all previous writes should have been written. > we already have an fsync that does that. Did you actually read the article...? The whole thing is about the fact that disk controllers can eagerly notify that a write was flushed to disk while in fact it is still in the disk write cache, and could have been either partially, fully or partly written, thus tricking fsync().
- josephg 3y ago
  > It's the same in this context. fsync uses a blocking API to implement atomicity No, it doesn’t. In that context fsync is a write barrier. It doesn’t make writes atomic. The difference is this: If you issue a handful of writes then your computer crashes, some, all or none of the writes may have completed. And some writes might be “skewed” - where part of the write succeeded and part did not. Atomicity means a set of actions happens as one indivisible unit, and it either all happens or all doesn’t happen. Think database transactions. Filesystem writes are not like that. They are not atomic operations[1]. Fsync does not change the behaviour of the write system call. Fsync only stalls your program until all writes have been written to disk, at least assuming your drive isn’t lying to you. Just like a memory barrier. If your computer crashes before fsync returns, all bets are off. [1] With the exception of aligned writes under the device block size. Allegedly. I’d still like to see this actually documented somewhere.