I'm not the author of the above proposal, but I'd imagine the implementation to be more in the same spirit as uring_io or EBPF: batch many operations together and execute them all at once, without interruption, without crossing multiple times between user-space and kernel-space, without resorting to implement the same guarantees on the side of the application which, inevitably, are going to be less efficient than those provided by the platform.
You fall into the same trap as many others who benchmark individual tiny features w/o seeing the larger picture where these features combined to accomplish the end goals. Applications want sane correctness guarantees, and if they try to accomplish those goals using existing tools they will have to use multiple features. Perhaps, individually, those features perform well, but in a useful (from the application standpoint) combination, they don't. And that combination is the one you need to benchmark.
Yeah my expectation is that this sort of thing would dramatically improve performance. Doing atomic operations on filesystems right now involve an awful lot of fdatasync() calls and some creative use of checksumming to avoid torn writes. A better designed API wouldn’t need all that guff, saving me (the application developer) from a lot of headaches and bugs. The kernel could almost certainly do a better job of all of that work internally, with less overhead than I can from user space.
My much more modest feature request from the kernel is a write barrier. If I’m using double-buffered pages or a write-ahead log, right now my code says write(); fsync(); write(); in order to ensure the log is written before updating the data itself. I don’t need the operating system to flush everything immediately - I just need to ensure the first write happens entirely before the second write begins. Like, I need to ensure order. A write barrier command is all I need here.
The posix filesystem apis are a sloppy mess. I have no doubt that the right apis would make my life better and improve the performance of my software.
I'm not the author of the above proposal, but I'd imagine the implementation to be more in the same spirit as uring_io or EBPF: batch many operations together and execute them all at once, without interruption, without crossing multiple times between user-space and kernel-space, without resorting to implement the same guarantees on the side of the application which, inevitably, are going to be less efficient than those provided by the platform.
You fall into the same trap as many others who benchmark individual tiny features w/o seeing the larger picture where these features combined to accomplish the end goals. Applications want sane correctness guarantees, and if they try to accomplish those goals using existing tools they will have to use multiple features. Perhaps, individually, those features perform well, but in a useful (from the application standpoint) combination, they don't. And that combination is the one you need to benchmark.