4 ms·
That is a killer for performance for databases
by ayende 4y ago
That is a killer for performance for databases
- pengaru 4y ago> That is a killer for performance for databases It's actually the thing you use instead of O_SYNC because it's expected to deliver better synchronous performance, tantamount to using fdatasync() vs. fsync(). A broken fdatasync() (or O_DSYNC) is kind of a serious problem.
- _vvhw 4y agoWe discovered this through our use of O_DSYNC, and O_SYNC also has the same problem. I think that for macOS so far, the focus has been on ordering guarantees, i.e. write barriers to reset the disk back to some atomic point in time after a crash. However, for distributed databases like TigerBeetle, we also need durability guarantees, i.e. be able to know that the disk has the data down cold, that the disk won't “forget” data that the node has underwritten and ACK'ed externally.
- _vvhw 4y agoYes, we were counting on O_DSYNC to set the FUA bit on the write syscall so that we could avoid an extra F_FULLFSYNC fcntl syscall.