4 ms·

When I got fed up with the way the OS handled writes 15 years ago in one of my (ordinary) applications, I wrote to a temp file in the same directory, closed the

by 13415 7y ago

When I got fed up with the way the OS handled writes 15 years ago in one of my (ordinary) applications, I wrote to a temp file in the same directory, closed the file, did the atomic filename swap, and then verified the integrity of the new file under new name by opening it again and comparing it byte for byte to the content to be stored. Only after that did the operation succeed. On failure, the file names were swapped again and an error was signaled to the user. The temp file remained on disk to avoid further data loss. I suppose that's not fast enough for a DB.

jjnoakes 7y ago
Are you guaranteed that the data you read back didn't come from kernel caches of the file system blocks? How do you know the data actually came back from physical storage?
- alain94040 7y ago
  Yes, but why can't we add an API, all the way down to the lowest levels of the hardware, that says "once I say this write is done, it will be readable again even after power-cycle". Achieving that guarantee is not impossible, but it needs to be explicit. It can't be inferred from other API calls.
  - charleslmunger 7y ago
    The behavior of fsync is a battle of OS developers and OEMs versus application and database developers. Gaming the implementation of fsync to do less than fully fsync makes benchmarks look amazing, improves user perceived latency, and reduces flash wear. On the other hand, it corrupts data - but that's rare, "the hardware is failing anyway", etc. That's how you end up with stuff like OS X's "no really, fsync" param [1], or Motorola shipping nobarrier on their phones. [2] [1] https://github.com/google/leveldb/issues/203#issuecomment-55007291 https://github.com/google/leveldb/issues/203#issuecomment-55... [2] http://taras.glek.net/post/Followup-on-Pixel-vs-Moto:fsync/ http://taras.glek.net/post/Followup-on-Pixel-vs-Moto:fsync/
    - layoutIfNeeded 7y ago
      My CPU can't isolate processes due to Intel cutting corners with speculative execution. My memory is vulnerable to row hammer due to vendors cutting corners while pushing for increased DRAM density. And my - supposedly - non-volatile storage is broken due to vendors gaming benchmarks with fsync. Is there any component in a modern consumer computer that isn't fundamentally broken in one way or another?
      - gmueckl 7y ago
        No. At most these components are as reliable as random noise allows them to be. That part is just physics.
      - the8472 7y ago
        That off switch in your PSU is a conceptually sound implementation. Not the one at the front, that's broken too.
      - syn0byte 7y ago
        What you call "broken" others call "performance choices". Except SSD controllers, they are big fat phonies. Look at how much slower CPUs are without those speculative execution tricks. I can buy gigabytes of RAM with a 20 I found in an old jacket. You can explore entire worlds consisting of gigabytes of high res textures and mesh data in near real-time, while downloading 4 new albums off the internet. Broken?
        adrianratnapala 7y ago
        > Look at how much slower CPUs are without those speculative execution tricks. But do I care? All my computers, except the really ancient phone I use, are snappy. Of course there are cases were CPU speed matters, but I don't know if they are any less obscure than the cases where timing attacks are a risk.
        zAy0LfpBZLC8mAC 7y ago
        > Broken? Yes, it is breaking the promise of what it is supposed to do. If fsync() was defined as "will ensure your data is on disk, unless that's kinda slow, then who knows", then the behaviour would not be broken, just potentially useless for many applications. But if you promise to ensure something is stored on disk, and then don't, that's the definition of being broken.
  - tempguy9999 7y ago
    on linux fsync (I think). On windows FILE_FLAG_WRITE_THROUGH ("Write operations will not go through any intermediate cache, they will go directly to disk"). It's all there. I agree with other poster, just cos you read back the file and it compared byte-for-byte, unless large it's likely to have come from the OS's RAM file cache.

by 13415 7y ago

jjnoakes 7y ago

Are you guaranteed that the data you read back didn't come from kernel caches of the file system blocks? How do you know the data actually came back from physical storage?

alain94040 7y ago
Yes, but why can't we add an API, all the way down to the lowest levels of the hardware, that says "once I say this write is done, it will be readable again even after power-cycle". Achieving that guarantee is not impossible, but it needs to be explicit. It can't be inferred from other API calls.
- charleslmunger 7y ago
  The behavior of fsync is a battle of OS developers and OEMs versus application and database developers. Gaming the implementation of fsync to do less than fully fsync makes benchmarks look amazing, improves user perceived latency, and reduces flash wear. On the other hand, it corrupts data - but that's rare, "the hardware is failing anyway", etc. That's how you end up with stuff like OS X's "no really, fsync" param [1], or Motorola shipping nobarrier on their phones. [2] [1] https://github.com/google/leveldb/issues/203#issuecomment-55007291 https://github.com/google/leveldb/issues/203#issuecomment-55... [2] http://taras.glek.net/post/Followup-on-Pixel-vs-Moto:fsync/ http://taras.glek.net/post/Followup-on-Pixel-vs-Moto:fsync/
  - layoutIfNeeded 7y ago
    My CPU can't isolate processes due to Intel cutting corners with speculative execution. My memory is vulnerable to row hammer due to vendors cutting corners while pushing for increased DRAM density. And my - supposedly - non-volatile storage is broken due to vendors gaming benchmarks with fsync. Is there any component in a modern consumer computer that isn't fundamentally broken in one way or another?
    - gmueckl 7y ago
      No. At most these components are as reliable as random noise allows them to be. That part is just physics.
    - the8472 7y ago
      That off switch in your PSU is a conceptually sound implementation. Not the one at the front, that's broken too.
    - syn0byte 7y ago
      What you call "broken" others call "performance choices". Except SSD controllers, they are big fat phonies. Look at how much slower CPUs are without those speculative execution tricks. I can buy gigabytes of RAM with a 20 I found in an old jacket. You can explore entire worlds consisting of gigabytes of high res textures and mesh data in near real-time, while downloading 4 new albums off the internet. Broken?
      - adrianratnapala 7y ago
        > Look at how much slower CPUs are without those speculative execution tricks. But do I care? All my computers, except the really ancient phone I use, are snappy. Of course there are cases were CPU speed matters, but I don't know if they are any less obscure than the cases where timing attacks are a risk.
      - zAy0LfpBZLC8mAC 7y ago
        > Broken? Yes, it is breaking the promise of what it is supposed to do. If fsync() was defined as "will ensure your data is on disk, unless that's kinda slow, then who knows", then the behaviour would not be broken, just potentially useless for many applications. But if you promise to ensure something is stored on disk, and then don't, that's the definition of being broken.
- tempguy9999 7y ago
  on linux fsync (I think). On windows FILE_FLAG_WRITE_THROUGH ("Write operations will not go through any intermediate cache, they will go directly to disk"). It's all there. I agree with other poster, just cos you read back the file and it compared byte-for-byte, unless large it's likely to have come from the OS's RAM file cache.