> Don't most of their problems go away No. Yes, you can fallocate. Yes, you can use AIO, or even better io_uring. Yes, you can use O_DIRECT ... if you want to

> Don't most of their problems go away No. Yes, you can fallocate. Yes, you can use AIO, or even better io_uring. Yes, you can use O_DIRECT ... if you want to give up caching and have to deal with alignment restrictions, and it turns out that O_DIRECT turns into O_SYNC in some unexpected edge cases. That gets you something that kind of sort of behaves like a block device, but that doesn't solve any of the problems the authors identify. * No transactional semantics. Roll your own. (I'm actually OK with this one BTW, but others feel differently.) * No help with slow metadata operations. Still slow if you're still using multiple files, or roll your own within a single file. * No improvement in support for new media types (e.g. shingled/zoned). In an ideal world, local filesystems would do a decent job supporting distributed filesystems (and other data stores). Instead, we're in a world where local filesystems fall short in many ways, and the solution to every deficiency is to avoid the local filesystem as much as possible. That way leads to silos and lock-in, so I don't think it's a good answer. Local filesystems need to be better, or someone needs to create an equally standard abstraction and set of tools to do what local filesytems can't.