4 ms·

Personally I think keeping it low level but predictable would be far saner approach. App knows what it want to do with data, filesystem can't. Just trimming all

by adql 4y ago

Personally I think keeping it low level but predictable would be far saner approach. App knows what it want to do with data, filesystem can't. Just trimming all of the inconsitencies (especially the "fun" around sync and cached access..) and it's already much better. Of course probably very hard to do without fucking up existing apps ;/ > Operating systems could support START TRANSACTION on filesystem operations, allowing multiple operations to be performed atomically and with isolation. No more having to reason carefully about which posix file operations are atomic, no more having to worry about temp file TOCTOU etc. And your performance goes absolutely to trash once you start trying to make filesystem act as transactional database. Especially if you then try to use the filesystem for a database. > fopen(..., 'r') could, by default, operate on a COW snapshot of a file rather than on the raw file on the filesystems. No more having to worry about races with other processes. Another "performance goes to trash" option. Sure, now more palatable with NVMes getting everywhere, but still a massive footgun > Temp files, like database temp tables, could by default only be visible to the current process (and optionally its children) or even the current thread. No more having to worry about temp file races and related issues. Already an option O_TMPFILE > O_TMPFILE (since Linux 3.11) > Create an unnamed temporary regular file. The pathname argument specifies a directory; an unnamed inode will be created >in that directory's filesystem. Anything written to the resulting > file will be lost when the last file descriptor is closed, unless the file is given a name. ... > Specifying O_EXCL in conjunction with O_TMPFILE prevents a temporary file from being linked into the filesystem in the >above manner. (Note that the meaning of O_EXCL in this case is differ- > ent from the meaning of O_EXCL otherwise.)

thefaux 4y ago
> Already an option O_TMPFILE This is not portable.
- karatinversion 4y ago
  Well obviously, this is a discussion of the limitations of posix. (Of course, as we see time and again, the real portability solution is for users to standardise on a single platform)
bsder 4y ago
> > fopen(..., 'r') could, by default, operate on a COW snapshot of a file rather than on the raw file on the filesystems. No more having to worry about races with other processes. > Another "performance goes to trash" option. Sure, now more palatable with NVMes getting everywhere, but still a massive footgun Only because the filesystems aren't built that way. ZFS could handle this just fine. The fact that adding SQLite into your application is often faster performance than doing raw disk accesses yourself says that our abstractions are wrong.
crabbone 4y ago
You are thinking about it wrong. 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.
- josephg 4y ago
  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.

by adql 4y ago

thefaux 4y ago

> Already an option O_TMPFILE This is not portable.

karatinversion 4y ago
Well obviously, this is a discussion of the limitations of posix. (Of course, as we see time and again, the real portability solution is for users to standardise on a single platform)

bsder 4y ago

> > fopen(..., 'r') could, by default, operate on a COW snapshot of a file rather than on the raw file on the filesystems. No more having to worry about races with other processes. > Another "performance goes to trash" option. Sure, now more palatable with NVMes getting everywhere, but still a massive footgun Only because the filesystems aren't built that way. ZFS could handle this just fine. The fact that adding SQLite into your application is often faster performance than doing raw disk accesses yourself says that our abstractions are wrong.

crabbone 4y ago

You are thinking about it wrong. 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.

josephg 4y ago
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.