3 ms·

All the data may be on the disk, but (last I checked) POSIX didn't require that filesystems not get completely corrupted in the event of a system crash. Obvious

All the data may be on the disk, but (last I checked) POSIX didn't require that filesystems not get completely corrupted in the event of a system crash. Obviously it would be nice if filesystems were not corrupted by a system crash, but I'm pretty sure POSIX doesn't guarantee it. And just because the data is on the disk, that (unfortunately) doesn't mean that you'll necessarily be able to find it. (shades of MS Fnd in a Lbry by Hal Draper here)

mehrdadn 6y ago
This is a bit like how a mail service might guarantee they'll deliver your mail to a safe mailbox at that address but not guarantee anything about who is at that address or whether they'll be reachable at any point in time. The only thing this establishes is that there are more issues to worry about than the one I was replying to. P.S. You don't even need a crash to induce the condition you're describing. Just call unlink() from another thread and suddenly fsync() will no longer be able to (and shouldn't) guarantee reachability...
- nh2 6y ago
  It's silly that this is being downvoted. Of course POSIX doesn't "require that filesystems not get completely corrupted in the event of a system crash", in the same way that it doesn't require that your RAM isn't faulty or that the computer manages to turn on at all after the next reboot. A software specification and its guarantees only make sense in the context of properly functioning hardware and surrounding software. In this case, that translates to "hardware doesn't randomly lose data" and "file systems do not randomly corrupt themselves", because that is the fundamental job of those systems. fsync() is about durability, telling the POSIX-implementing OS interface to instruct the underlying software (e.g. file system) and hardware to sync the described volatile data into persistent state. For a system running on a ramdisk, that naturally means a no-op; for a network mount it means a roundtrip; for a PC with a hard disk it means that the described data is now on disk, and that it is there, uncorrupted, after an ordinary power failure. If you have broken RAM, a disk that lies about flush commands, or synced only a part of the intended data (forgotten to fsync the dir), then the POSIX system has still done its job regarding durability, and fulfilled its guarantees.
tomtomtom777 6y ago
> All the data may be on the disk, but (last I checked) POSIX didn't require that filesystems not get completely corrupted in the event of a system crash. It does. It specifies how the filesystem should behave in a particular (non corrupted) way. There is no exception that this requirement is somehow voided if the system wasn't cleanly shutdown.

mehrdadn 6y ago

This is a bit like how a mail service might guarantee they'll deliver your mail to a safe mailbox at that address but not guarantee anything about who is at that address or whether they'll be reachable at any point in time. The only thing this establishes is that there are more issues to worry about than the one I was replying to. P.S. You don't even need a crash to induce the condition you're describing. Just call unlink() from another thread and suddenly fsync() will no longer be able to (and shouldn't) guarantee reachability...

nh2 6y ago
It's silly that this is being downvoted. Of course POSIX doesn't "require that filesystems not get completely corrupted in the event of a system crash", in the same way that it doesn't require that your RAM isn't faulty or that the computer manages to turn on at all after the next reboot. A software specification and its guarantees only make sense in the context of properly functioning hardware and surrounding software. In this case, that translates to "hardware doesn't randomly lose data" and "file systems do not randomly corrupt themselves", because that is the fundamental job of those systems. fsync() is about durability, telling the POSIX-implementing OS interface to instruct the underlying software (e.g. file system) and hardware to sync the described volatile data into persistent state. For a system running on a ramdisk, that naturally means a no-op; for a network mount it means a roundtrip; for a PC with a hard disk it means that the described data is now on disk, and that it is there, uncorrupted, after an ordinary power failure. If you have broken RAM, a disk that lies about flush commands, or synced only a part of the intended data (forgotten to fsync the dir), then the POSIX system has still done its job regarding durability, and fulfilled its guarantees.

tomtomtom777 6y ago

> All the data may be on the disk, but (last I checked) POSIX didn't require that filesystems not get completely corrupted in the event of a system crash. It does. It specifies how the filesystem should behave in a particular (non corrupted) way. There is no exception that this requirement is somehow voided if the system wasn't cleanly shutdown.