You can imagine that Jepsen could run against filesystems itself. Basic JVM IO would be fairly easy to get going, and the POSIX APIs could be tested by having Jepsen call (maybe via IPC?) a small C/whatever binary. I don't know what fault injection would look like though: presumably you'd want to do something down in the kernel/device drivers/hw, and that land is largely a mystery to me.
Tangentially, I would love to have a FUSE filesystem with a.) minimal build dependencies, b.) some sort of CLI interface, and c.) the ability to, say, forget to flush un-fsynced data to "disk", allowing us to simulate a power failure. There have been a bunch of research projects on this front, and they find bugs spectacularly. I bet this approach would also find errors in distributed systems, but I've yet to find one that really has the right shape for use with Jepsen.
This is probably not relevant to Jepsen, and I don't know how similar to a distributed database distributed metadata in parallel filesystems look. Anyway, some of the tests for the Lustre PFS use Linux' fault injection system. Also, Linux documents specific support for NFS fault injection, which I know nothing about, and may or may not apply to pNFS. (It probably doesn't make it any more relevant or databased, but the OrangeFS PFS uses bdb or lmdb instances for the arbitrarily distributed metadata.)
Tangentially, I would love to have a FUSE filesystem with a.) minimal build dependencies, b.) some sort of CLI interface, and c.) the ability to, say, forget to flush un-fsynced data to "disk", allowing us to simulate a power failure. There have been a bunch of research projects on this front, and they find bugs spectacularly. I bet this approach would also find errors in distributed systems, but I've yet to find one that really has the right shape for use with Jepsen.