3 ms·
> Have either database-like transactions or (at a minimum) write barriers for file operations. Go one step further and have the kernel expose a much more struc
by cbdumas 3y ago
> Have either database-like transactions or (at a minimum) write barriers for file operations.
Go one step further and have the kernel expose a much more structured view of storage to user space by default. 99.9% of user space programs I've written don't want to deal with file IO, they want a database, or some other way for arbitrary in memory objects to be persisted and shared between processes. There's so much room to improve on the 1970s era IO primitives we use by default.
- didntcheck 3y agoIronically my understanding is that several operating systems around that time did do that, then Unix came and said "a file is just a bag of bytes in a hierarchical namespace" and we've seemingly never reconsidered
- nerdponx 3y agoI can imagine that there's a major lack of flexibility inherent in a record-based filesystem. Nowadays we have file formats that introduce a record format on top of the "bag of bytes" for when you want records, but you aren't required to have records of any particular shape and size (or have any records at all) if they don't work for your needs.
- snuxoll 3y agoNotable major player here was IBM on the AS/400, you had libraries containing objects of various types (such as PGM/Program, FILE/'file', *DTAQ/Data Queue, etc). 'file' objects were effectively database tables, and even things like source code for programs were stored as such. Eventually IBM added the IFS (integrated file system) to provide a more traditional POSIX-adjacent filesystem that was in fact just a bunch of bits, and it feels weird and out of place with the rest of the system as a result.