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.
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.