Hi, On 2019-04-11 09:06:55 -0600, Jens Axboe wrote: > There are no ordering constraints between the submission and completion > side of io_uring. But sometimes that would be useful to have. One common > example is doing an fsync, for instance, and have it ordered with > previous writes. Without support for that, the application must do this > tracking itself. The facility seems useful for at least this postgres developer playing with optionally using io_uring in parts of postgres. As you say, I'd otherwise need to manually implement drains in userland. > This adds a general SQE flag, IOSQE_IO_DRAIN. If a command is marked > with this flag, then it will not be issued before previous commands have > completed, and subsequent commands submitted after the drain will not be > issued before the drain is started.. If there are no pending commands, > setting this flag will not change the behavior of the issue of the > command. I think it'd be good if there were some documentation about how io_uring interacts with writes done via a different io_uring queue, or traditional write(2) et al. And whether IOSQE_IO_DRAIN drain influences that. In none of the docs I read it's documented if an io_uring fsync guarantees that a write(2) that finished before an IORING_OP_FSYNC op is submitted is durable? Given the current implementation that clearly seems to be the case, but it's not great to rely on the current implementation as a user of data integrity operations. Similarly, it'd be good if there were docs about how traditional read/write/fsync and multiple io_uring queues interact in the face of concurrent operations. For plain read/write we have posix providing some baseline guarantees, but obviously doesn't mean anything for io_uring. I suspect that most people's intuition will be "it's obvious", but also that such intuitions are likely to differ between people. Greetings, Andres Freund
