Besides, an asynchronous fsync doesn't actually address the other benefit of the rename pattern: atomicity. That's just as important as durability. If you want to replace atomic rename, what you really want is a general transactional filesystem API.

(Latest I can find on writes: "There's no RWF_NOWAIT support for *write* in pwritev2. But it's technically possible to implement it"...)

For other buffered IO with io_uring, you get a convenient kernel thread pool which is managed automatically. This was already required by the above.

I don't know exactly why IOCB_CMD_FSYNC + io_submit() was considered useful v.s. a simple thread pool example; you might be right about that.

"io_pgetevents & aio fsync V4" https://lore.kernel.org/lkml/20180502211448.18276-1-hch@l...

"Re: Triggering non-integrity writeback from userspace" https://lore.kernel.org/lkml/20151029221022.GB10656@dastard/

For io_uring "kernel side polling" IO, I belive it lets you avoid system call overheads altogether, while a kernel thread continuously polls for IO completions on your super-fast device. It has an option to set the affinity of the kernel thread.

For "regular application development," what you (probably) want is something along the lines of "atomically replace the contents of file foo with data bar, but I don't care about ordering or durability." This is traditionally expressed by writing it to a temp file and doing a rename() over the existing file. Technically, you are required to fsync() or fdatasync() the temp file* to prevent the write from being ordered after the rename, but many applications skip this step. In practice it is desirable that the filesystem detect this case and handle it automatically. Then you don't use any sync primitives, don't get durability, do get ordering, and end up with reasonable performance. Best of all, this provides transparent support for apps that only care "a little bit" about doing things correctly, which is probably most of them. You'll still have pain from open(..., O_WRONLY|O_TRUNC) on an existing file, of course, but that's your own fault and you should fix your ways.

For databases, you definitely want durability in addition to sequencing, so that you know when you can mark the transaction as committed. However, databases have a lot of other, more complicated needs, and they tend to drive new filesystem features to an accordingly greater degree than "regular applications." I therefore am hesitant to make an across-the-board pronouncement about what they need, but in general, fsync() is a significant part of what they need.

The tricky part comes from the rare "in between" cases, where you might have multiple files and want to mutate them all transactionally (e.g. because you are writing a package manager and want to transactionally install a package). Surprisingly, NTFS actually has support for this, but MSDN** says it's a Bad Thing that you should avoid using. To the best of my knowledge, this is completely unsupported on (most mainstream) Linux filesystems.

* Or open with O_SYNC, but to a first approximation, nobody does that.
** https://docs.microsoft.com/en-us/windows/desktop/fileio/d...

But it sacrifices nothing to provide an async alternative for those whom it benefits.

It's definitely NOT a marketing win when said user discovers that removing the fsync results in faster performance by orders of magnitude! (Or the other way round - adding it makes the machine run as slow as treacle.)

For most users - including databases most of the time I would have thought - a simple write barrier is sufficient. That way you get guaranteed consistency - if the log isn't written you lose the transaction completely, while if it is written then the database write can be replayed. The barrier needs to be on a "by user" or "by application" basis, though. Not on an fd basis because quite often logs and data are written to different files and we don't want file b to start updating until file a has finished. Making it system-wide might not punish performance that much on a not too heavily loaded system.

If the caller can choose between an asynchronous "fire and forget" barrier, and a synchronous "wait until it completes" barrier, then all the better. Make it two synchronous barriers - a "manyana" version and an "asap" version (the latter basically telling the system to "flush it all NOW"), and then it allows the APPLICATION to decide what's important.

There's no point having an operating system that runs the computer according the needs of the OS. Without applications there's no point in having the computer!

Cheers,
Wol