5 ms·

> Durability is about systems that are shut down (possibly unexpected and in an uncontrolled manner). POSIX is carefully worded to not give any durability guara

> Durability is about systems that are shut down (possibly unexpected and in an uncontrolled manner). POSIX is carefully worded to not give any durability guarantees. What part of the POSIX specs are you reading? "The fsync() function shall request that all data for the open file descriptor named by fildes is to be transferred to the storage device associated with the file described by fildes. [...] The fsync() function is intended to force a physical write of data from the buffer cache, and to assure that after a system crash or other failure that all data up to the time of the fsync() call is recorded on the disk." https://pubs.opengroup.org/onlinepubs/9699919799/functions/fsync.html https://pubs.opengroup.org/onlinepubs/9699919799/functions/f...

chrisseaton 6y ago
How can software possibly be expected to ensure what a physical device returns after the system restarts? I would guess that 'intended to' is there very specifically to ensure that this statement really means... nothing at all. It can fail but if it 'intended to' succeed that's enough. If your system crashes due to a power surge that breaks your hard drive... guess what it isn't going to give you back the bytes you wanted.
- mehrdadn 6y ago
  > How can software possibly be expected to ensure what a physical device returns after the system restarts? By giving instructions to the device that the device understands and provides guarantees for...
  - chrisseaton 6y ago
    How can the device provide those guarantees? If the system crashes hard in a power surge and the head crashes there's not going to be any use in claiming 'but the API guaranteed it'. There's no true durability.
    - mehrdadn 6y ago
      > How can the device provide those guarantees? If the system crashes hard in a power surge and the head crashes there's not going to be any use in claiming 'but the API guaranteed it'. There's no true durability. By your logic there is no such thing as a guarantee in this world, period. A meteor could crash into Earth and wreck everything.
      - chrisseaton 6y ago
        > Very astute observation. You're being snarky. That's not allowed in the rules here and it's unkind even if it wasn't. > By your logic there is no such thing as a guarantee in this world, period. So what does the guarantee really mean? That the data will be on disk... as long as the crash isn't too hard? What do you usefully do with this guarantee? How is it better than no guarantee?
        mehrdadn 6y ago
        Okay, I removed that phrase, but what do you want me to say here? Entire disciplines have devoted decades of research into providing useful guarantees and yet you're here observing that no human could possibly prevent some disasters... and using that logic to just trash everything and everyone's associated work along the way. I mean, you're clearly technically right that there is no such thing as an absolute guarantee, but... what am I supposed to do with this assertion? Find it insightful? Give up on the notion of a guarantee? Declare everything is useless? What response were you hoping for that you're still not getting?
        chrisseaton 6y ago
        Why do you think the phrasing 'shall request ... is intended to' means there? It's a trapdoor for 'actually guarantees nothing', right?
        mehrdadn 6y ago
        It means: "In case we didn't get the point across in the technical language above, this is what we're trying to say in plain English." It does not mean "we're just writing this superfluous text to clock in extra hours or pass a word count threshold".
  - formerly_proven 6y ago
    On hard drives, even SATA ones this is mostly sorted out since a few years (Linux doesn't use FUA over SATA, leaves write-back drive cache enabled, and just issues a full cache flush, which the big majority of drives respect, more or less). SSDs, less so, fsync is a rather relative affair on some of them. IMHO, from having spent a fair amount of time on this, durability is a "fluid" concept, especially on desktop hardware (Microsoft had the right idea when they built Win Update on TxF), so if the data is important enough to worry about it, you should architect the system in a way that the durability of a fildes or drive is irrelevant to the overall system.
    - mehrdadn 6y ago
      Right, but that's only because drives are lying at that point (or implemented so incompetently they have no idea they're lying...). Linux is trying to force liars to do what it wants anyway, and hence as a practical matter, programs need to worry about this too. This doesn't mean the spec is somehow broken or that honest (and competent) implementers couldn't guarantee durability if they wanted to.
Karellen 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. 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.
formerly_proven 6y ago
The language you are quoting is quite clear that the behavior you are thinking about is implementation-defined, and the informative section clarifies that this is one-hundred percent intended. > It is explicitly intended that a null implementation is permitted.
- mehrdadn 6y ago
  No, a null implementation is permitted because write() could potentially already provide these guarantees internally, at which point fsync() would be able to satisfy all requirements without needing to do anything. That sentence does not mean you could take any arbitrary system and slap a no-op fsync() onto it and somehow still maintain these guarantees.
  - formerly_proven 6y ago
    The next sentence in the document would have told you that this conception is simply wrong. fsync does not give you durability guarantees. POSIX is worded such that a system with no durability can be compliant. > It is explicitly intended that a null implementation is permitted. This could be valid in the case where the system cannot assure non-volatile storage under any circumstances or when the system is highly fault-tolerant and the functionality is not required. In the middle ground between these extremes, fsync() might or might not actually cause data to be written where it is safe from a power failure. The conformance document should identify at least that one configuration exists (and how to obtain that configuration) where this can be assured for at least some files that the user can select to use for critical data. It is not intended that an exhaustive list is required, but rather sufficient information is provided so that if critical data needs to be saved, the user can determine how the system is to be configured to allow the data to be written to non-volatile storage. Again, the way the normative language you quoted above is written makes it abundantly clear (for a standard) that fsync doing anything is entirely optional.
    - mehrdadn 6y ago
      Did you read the first sentence in that paragraph? That entire paragraph is talking about when _POSIX_SYNCHRONIZED_IO is not defined: > If _POSIX_SYNCHRONIZED_IO is not defined, the wording relies heavily on the conformance document to tell the user what can be expected from the system. [...] If you check your Linux system, you will see _POSIX_SYNCHRONIZED_IO is defined: printf "%s\n" "#include <unistd.h>" "#ifdef _POSIX_SYNCHRONIZED_IO" "#error _POSIX_SYNCHRONIZED_IO is defined" "#endif" | gcc -fsyntax-only -x c - and hence the rest of that paragraph isn't talking about this situation.

chrisseaton 6y ago

How can software possibly be expected to ensure what a physical device returns after the system restarts? I would guess that 'intended to' is there very specifically to ensure that this statement really means... nothing at all. It can fail but if it 'intended to' succeed that's enough. If your system crashes due to a power surge that breaks your hard drive... guess what it isn't going to give you back the bytes you wanted.

mehrdadn 6y ago
> How can software possibly be expected to ensure what a physical device returns after the system restarts? By giving instructions to the device that the device understands and provides guarantees for...
- chrisseaton 6y ago
  How can the device provide those guarantees? If the system crashes hard in a power surge and the head crashes there's not going to be any use in claiming 'but the API guaranteed it'. There's no true durability.
  - mehrdadn 6y ago
    > How can the device provide those guarantees? If the system crashes hard in a power surge and the head crashes there's not going to be any use in claiming 'but the API guaranteed it'. There's no true durability. By your logic there is no such thing as a guarantee in this world, period. A meteor could crash into Earth and wreck everything.
    - chrisseaton 6y ago
      > Very astute observation. You're being snarky. That's not allowed in the rules here and it's unkind even if it wasn't. > By your logic there is no such thing as a guarantee in this world, period. So what does the guarantee really mean? That the data will be on disk... as long as the crash isn't too hard? What do you usefully do with this guarantee? How is it better than no guarantee?
      - mehrdadn 6y ago
        Okay, I removed that phrase, but what do you want me to say here? Entire disciplines have devoted decades of research into providing useful guarantees and yet you're here observing that no human could possibly prevent some disasters... and using that logic to just trash everything and everyone's associated work along the way. I mean, you're clearly technically right that there is no such thing as an absolute guarantee, but... what am I supposed to do with this assertion? Find it insightful? Give up on the notion of a guarantee? Declare everything is useless? What response were you hoping for that you're still not getting?
        chrisseaton 6y ago
        Why do you think the phrasing 'shall request ... is intended to' means there? It's a trapdoor for 'actually guarantees nothing', right?
        mehrdadn 6y ago
        It means: "In case we didn't get the point across in the technical language above, this is what we're trying to say in plain English." It does not mean "we're just writing this superfluous text to clock in extra hours or pass a word count threshold".
- formerly_proven 6y ago
  On hard drives, even SATA ones this is mostly sorted out since a few years (Linux doesn't use FUA over SATA, leaves write-back drive cache enabled, and just issues a full cache flush, which the big majority of drives respect, more or less). SSDs, less so, fsync is a rather relative affair on some of them. IMHO, from having spent a fair amount of time on this, durability is a "fluid" concept, especially on desktop hardware (Microsoft had the right idea when they built Win Update on TxF), so if the data is important enough to worry about it, you should architect the system in a way that the durability of a fildes or drive is irrelevant to the overall system.
  - mehrdadn 6y ago
    Right, but that's only because drives are lying at that point (or implemented so incompetently they have no idea they're lying...). Linux is trying to force liars to do what it wants anyway, and hence as a practical matter, programs need to worry about this too. This doesn't mean the spec is somehow broken or that honest (and competent) implementers couldn't guarantee durability if they wanted to.

Karellen 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. 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.

formerly_proven 6y ago

The language you are quoting is quite clear that the behavior you are thinking about is implementation-defined, and the informative section clarifies that this is one-hundred percent intended. > It is explicitly intended that a null implementation is permitted.

mehrdadn 6y ago
No, a null implementation is permitted because write() could potentially already provide these guarantees internally, at which point fsync() would be able to satisfy all requirements without needing to do anything. That sentence does not mean you could take any arbitrary system and slap a no-op fsync() onto it and somehow still maintain these guarantees.
- formerly_proven 6y ago
  The next sentence in the document would have told you that this conception is simply wrong. fsync does not give you durability guarantees. POSIX is worded such that a system with no durability can be compliant. > It is explicitly intended that a null implementation is permitted. This could be valid in the case where the system cannot assure non-volatile storage under any circumstances or when the system is highly fault-tolerant and the functionality is not required. In the middle ground between these extremes, fsync() might or might not actually cause data to be written where it is safe from a power failure. The conformance document should identify at least that one configuration exists (and how to obtain that configuration) where this can be assured for at least some files that the user can select to use for critical data. It is not intended that an exhaustive list is required, but rather sufficient information is provided so that if critical data needs to be saved, the user can determine how the system is to be configured to allow the data to be written to non-volatile storage. Again, the way the normative language you quoted above is written makes it abundantly clear (for a standard) that fsync doing anything is entirely optional.
  - mehrdadn 6y ago
    Did you read the first sentence in that paragraph? That entire paragraph is talking about when _POSIX_SYNCHRONIZED_IO is not defined: > If _POSIX_SYNCHRONIZED_IO is not defined, the wording relies heavily on the conformance document to tell the user what can be expected from the system. [...] If you check your Linux system, you will see _POSIX_SYNCHRONIZED_IO is defined: printf "%s\n" "#include <unistd.h>" "#ifdef _POSIX_SYNCHRONIZED_IO" "#error _POSIX_SYNCHRONIZED_IO is defined" "#endif" | gcc -fsyntax-only -x c - and hence the rest of that paragraph isn't talking about this situation.