4 ms·
> There's no getting around fsync if you want to be sure that your data is really on the storage medium. That's not correct; io_uring supports O_DIRECT write r
by ajross 1y ago
> There's no getting around fsync if you want to be sure that your data is really on the storage medium.
That's not correct; io_uring supports O_DIRECT write requests just fine. Obviously bypassing the cache isn't the same as just flushing it (which is what fsync does), so there are design impacts.
But database engines are absolutely the target of io_uring's feature set and they're expected to be managing this complexity.
- zozbot234 1y agoThat's not what O_DIRECT is for. Did you mean O_SYNC ?
- codys 1y ago> But database engines are absolutely the target of io_uring's feature set and they're expected to be managing this complexity. io_uring includes an fsync opcode (with range support). When folks talk about fsync generally here, they're not saying the io_uring is unusable, they're saying that they'd expect the fsync to be used whether it's via the io_uring opcode, the system call, or some other mechanism yet to be created.
- jandrewrogers 1y agoO_DIRECT is not a substitute for fsync(). It only guarantees that data gets to the storage device cache, which is not durable in most cases.
- somat 1y agoMy understanding is that the storage device cache is opaque, that is, drives tend to lie, saying the write is done when it is in cache, and depend on having enough internal power capacity to flush on power loss.
- loeg 1y agoConsumer devices sometimes lie (enterprise products less so), but there is a distinction between O_DIRECT and actual fsync at the protocol layer (e.g., in NVMe, fsync maps into a Flush command).
- quietbritishjim 1y agoIs that's true (notwithstanding objections from sibling comments) then that's just another spelling of fsync. My point was really: you can't magically get the performance benefits of omitting fsync (or functional equivalent) while still getting the durability guarantees it gives.