What's So Bad About Posix I/O?

Re:What's So Bad About Posix I/O? by nwatson on Tuesday September 12, 2017 @01:05AM (#15224938)

For this ...

    Any successful read() from each byte position in the file that  was
    modified  by  that  write  shall  return  the data specified by the write()

... perhaps I can re-open() and re-read() the same byte value written by another process for the same file, but the file contents may not have been fully flushed all the way to disk. The file contents may be "durable" across processes on the same running OS that mount the same filesystem ... but if the OS happens to die before the data is flushed, then perhaps after reboot the open()/read() will return an older value previously written.

The semantics of "durability" are a squishy concept.

[ Parent | on HN ]

Re:What's So Bad About Posix I/O? by aidenn0 on Tuesday September 12, 2017 @02:45AM (#15225284)

yes, the term "durable" was perhaps a poor choice of words, but the paragraph that followed made it clear that they were aware of the specific requirements (specifically mentioning making dirty caches available to all processes)

[ Parent | on HN ]

Re:What's So Bad About Posix I/O? by dom0 on Tuesday September 12, 2017 @05:05AM (#15225846)

Durable has a very specific meaning for I/O and is just not correct here.

POSIX does intentionally not specify any durability at all (e.g. a no-op fsync is explicitly permitted).

[ Parent | on HN ]

Re:What's So Bad About Posix I/O? by dullgiulio on Tuesday September 12, 2017 @05:32AM (#15225949)

And in practice it is close to that, due to cheating hardware with a cache.

[ Parent | on HN ]

Re:What's So Bad About Posix I/O? by AstralStorm on Tuesday September 12, 2017 @03:27AM (#15225445)

You can actually do that with mmap and if you want shm. (Mmap works on files well.) Of course then you have to deal with all the dirt yourself.

[ Parent | on HN ]