I have basically the opposite problem. I've been looking for a filesystem that maximizes performance (and minimizes actual disk writes) at the cost of reliability. As long as it loses all my data less than once a week, I can live with it.
You could also look at this: https://rwmj.wordpress.com/2020/03/21/new-nbdkit-remote-tmpf... We use it for Koji builds, where we actually don't care about keeping the build tree around (we persist only the built objects and artifacts elsewhere). This plugin is pretty fast for this use case because it ignores FUA requests from the filesystem. Obviously don't use it where you care about your data.
Uhh hello, pricing ?
> maybe disable flushes with https://github.com/stewartsmith/libeatmydata
overlayfs has a volatile mount option that has that effect. So stacking a volatile overlayfs with the upper and lower on the same ext4 could provide that behavior even for applications that can't be intercepted with LD_PRELOAD
[1]: https://www.kernel.org/doc/Documentation/blockdev/ramdisk.tx...
[2]: https://blog.delouw.ch/2020/01/29/using-lvm-cache-for-storag...
Because I have the best storage performance you'll ever find anywhere, 100% money-back guaranteed: write to /dev/null. It comes with the downside of 0% reliability.
You can write to a disk without a file-system, sequentially, until space ends. Quite fast actually, and reliable, until you reach the end, then reliability drops dramatically.
P.S. I'm fairly certain that /dev/null would lose my data a bit more often than once a week.
On a related note, though, I've considered the idea of creating a "minimally POSIX-compliant" filesystem that randomly reorders and delays I/O operations whenever standards permit it to do so, along with any other odd behavior I can find that remains within the letter of published standards (unusual path limitations, support for exactly two hard links per file, sparse files that require holes to be aligned on 4,099-byte boundaries in spite of the filesystem's reported 509-byte block size, etc., all properly reported by applicable APIs).
If the stripe dies, worst case is I lose up to one hour of work, plus let's say another hour copying assets back to a rebuilt stripe.
There are so many MASSIVE files created in intermediate stages of audiovisual [post] production.
Any files that are important would go to a separate, more reliable filesystem (or uploaded elsewhere).