3 ms·

So I never dug deep into the POSIX but I still miss this question answered before I accept the blog post's premise: What's wrong with the standard procedure

So I never dug deep into the POSIX but I still miss this question answered before I accept the blog post's premise: What's wrong with the standard procedure 1. open / create file 2. write to file 3. sync file 4. possibly rename file to final location 5. sync parent directory of file Which compliant file systems don't guarantee that this is durable (notwithstanding disks that tell lies)? Maybe POSIX doesn't specify this exact sequence explicitly (don't know), but this is the folklore which you find everywhere, and it's just what you arrive at naturally when you consider the object model on which the API is built (where an object is an "open file", i.e. what fds reference). (I mentioned this: it's basically the model that git also adopts, except that git objects are immutable).

daurnimator 11y ago
The issue is that most programs do not do step 3: e.g. fsync is not called by C's stdio. Which means that the `rename` might get reordered before the `write`. Which means data loss. yay!
- jstimpfle 11y ago
  The discussion hasn't been about stdio so far. Btw. my fflush(3) manpage does mention that fsync(2) is required to ensure data reaches the disk. Of course it's not nice that we have to drop abstractions (and portability) to go the safe way. Let's just say stdio is a bit simplistic. Btw. many file systems don't reorder write and rename for exactly this reason. But at least ext2 and btrfs seem to do it.
thatcks 11y ago
What is wrong with the standard procedure is that once upon a time the standard procedure that everyone knew and coded to was steps 1 through 4, without step 5. Then Linux ext4 people decided that step 5 was necessary, or rather that they could optimize ext4 to delay and lose some writes if you left out step 5. Which lots of people did, and so some people unexpectedly lost data and were unhappy. If we have only a standard procedure and not an actual agreed on standard (whether or not it's a formal one), we are forever vulnerable to the next clever filesystem developer who decides that obviously they can get away with adding a new step 6, or 7, or 8 in some situations, under some interpretation of the POSIX or Single Unix Specification wording, or the Linux manpages, or whatever. (I'm the author of the linked-to blog entry.)

daurnimator 11y ago

The issue is that most programs do not do step 3: e.g. fsync is not called by C's stdio. Which means that the `rename` might get reordered before the `write`. Which means data loss. yay!

jstimpfle 11y ago
The discussion hasn't been about stdio so far. Btw. my fflush(3) manpage does mention that fsync(2) is required to ensure data reaches the disk. Of course it's not nice that we have to drop abstractions (and portability) to go the safe way. Let's just say stdio is a bit simplistic. Btw. many file systems don't reorder write and rename for exactly this reason. But at least ext2 and btrfs seem to do it.

thatcks 11y ago

What is wrong with the standard procedure is that once upon a time the standard procedure that everyone knew and coded to was steps 1 through 4, without step 5. Then Linux ext4 people decided that step 5 was necessary, or rather that they could optimize ext4 to delay and lose some writes if you left out step 5. Which lots of people did, and so some people unexpectedly lost data and were unhappy. If we have only a standard procedure and not an actual agreed on standard (whether or not it's a formal one), we are forever vulnerable to the next clever filesystem developer who decides that obviously they can get away with adding a new step 6, or 7, or 8 in some situations, under some interpretation of the POSIX or Single Unix Specification wording, or the Linux manpages, or whatever. (I'm the author of the linked-to blog entry.)