Comment by lisper
10 years ago
That's not guaranteed to work in the face of crashes. The problem is that the directory update could get flushed to disk before the file data.
This is the fundamental problem: When you allow the OS (or the compiler, or the CPU) to re-order operations in the name of efficiency you lose control over intermediate states, and so you cannot guarantee that these intermediates states are consistent with respect to the semantics that you care about. And this is the even more fundamental problem: our entire programming methodology has revolved around describing what we want the computer to do rather than what we want to to achieve. Optimizations then have to reverse-engineer our instructions and make their best guesses as to what we really meant (e.g. "This is dead code. It cannot possibly affect the end result. Therefore it can be safely eliminated.) Sometimes (often?) those guesses are wrong. When they are, we typically only find out about it after the mismatch between our expectations and the computer's have manifested themselves in some undesirable (and often unrecoverable) way.
"That's not guaranteed to work in the face of crashes. The problem is that the directory update could get flushed to disk before the file data."
No, it can work, provided that the temporary file is fsynced before being renamed, the parent directory is fsynced after renaming the file, and that the application only considers the rename to have taken place after the parent directory is fsynced (not after the rename call itself).
FSYNC is not enough. You also have to make sure that NCQ is disabled:
https://en.wikipedia.org/wiki/Native_Command_Queuing
OS can use Force Unit Access flag with NCQ to control disk buffering: https://en.wikipedia.org/wiki/Disk_buffer#Force_Unit_Access_...
Good summary of the situation. It's why I fought out-of-order execution at hardware and OS levels as much as I could. Even went out of way to use processors that didn't do it. Market pushed opposite stuff into dominance. Then came the inevitable software re-writes to get predictability and integrity out of what shouldn't have problems in the first place. It's all ridiculous.