The answer is io_uring, and it does already have fsync() in addition to sync_file_range().https://twitter.com/lwnnet/status/1130971376712638465 …
-
-
Replying to @axboe
Is there a chance it could make sense to somehow allow plug/unpluging IO requests across fsyncs to multiple fds? To create the minimal amount of IO, when latency isn't critical?
1 reply 0 retweets 2 likes -
Replying to @AndresFreundTec
I think what you're suggesting is what the article already hints at, a way to fsync() a number of fds. More of a coalescing of fsync()'s? Might make more sense if you could detail exactly what kind of semantics you would want.
1 reply 0 retweets 0 likes -
Replying to @axboe
I don't think I *actually* want quite that - the error reporting seems like it'd be weird. I'd rather just be able to asynchronously submit multiple fsyncs, and handle them in a single flush operation from the FS side.
1 reply 0 retweets 0 likes -
Replying to @AndresFreundTec
Not sure io_uring needs anything special to support that, that would mostly require some VFS plumbing to pass that bundle further down the stack without splitting it up. I do agree that the API and error handling would be way cleaner keeping them separate in terms of reporting.
1 reply 0 retweets 0 likes -
Replying to @axboe
I was thinking that it'd be useful to be able to limit the number of fsyncs etc that are grouped together. A database would e.g. want to fdatasync the minimal for a OLTP foreground commit. But do bulk-fsync for checkpointing, bulk writes, etc.
2 replies 0 retweets 0 likes
Could, I guess, also be achieved by separate queues, or at least separate submissions. Seems like it could add unnecessary complexity though.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.