People have created FUSE filesystems backed by SQLite before, but I don’t see how you’d get much unique value out of an RDBMS as filesystem if you’re only interacting with is through a traditional non-transactional byte stream API.
Vendors who have done this like IBM with the AS/400 have typically put the database APIs front and center in their sales pitches, and POSIX on AS/400 is more akin to WSL than something well-integrated into the traditional single-level store (or at least was a few years ago when I last took a look at it).
If you’re _only_ interacting with it through a traditional filesystem API, the benefits are small — you could just embed an existing format like qcow2 into the file probably.
But if a “legacy” application is only interacting with the filesystem through filesystem APIs, but you as a developer can interact with it as if it were a database (with transactional semantics that extend beyond the virtual inode boundary), I think it can still be very valuable.
Comments
People have created FUSE filesystems backed by SQLite before, but I don’t see how you’d get much unique value out of an RDBMS as filesystem if you’re only interacting with is through a traditional non-transactional byte stream API.
Vendors who have done this like IBM with the AS/400 have typically put the database APIs front and center in their sales pitches, and POSIX on AS/400 is more akin to WSL than something well-integrated into the traditional single-level store (or at least was a few years ago when I last took a look at it).
If you’re _only_ interacting with it through a traditional filesystem API, the benefits are small — you could just embed an existing format like qcow2 into the file probably.
But if a “legacy” application is only interacting with the filesystem through filesystem APIs, but you as a developer can interact with it as if it were a database (with transactional semantics that extend beyond the virtual inode boundary), I think it can still be very valuable.