I don't quite disagree with your conclusion, but some of your supporting points don't really support it. > If any of those filesystems were truly adequate ther

I don't quite disagree with your conclusion, but some of your supporting points don't really support it. > If any of those filesystems were truly adequate there wouldn't have to be so many. Diversity is not bad. Different filesystems can have different design points, e.g. read-heavy vs. write-heavy workloads, optimized for different kinds of media, realtime requirements (traditionally an XFS strength) etc. That's a good thing. What's a problem is that there are too many filesystems trying to be all things to all users of a too-general API, and too many FS developers competing with each other on long-irrelevant microbenchmarks instead of making useful progress. > Microsoft's failure ...is Microsoft's. > Recently ... pwrite, pread Those have been standardized since 1998, and I'm pretty sure I remember them existing on some systems before that. The fact that they're not recent is IMO the real problem. There have been attempts to create useful new abstractions such as the setstream API from CCFS[1], but they're too few and rarely gain traction. Personally, I think local filesystems need to adapt in a bunch of ways to be a better substrate for higher-level applications - including but not limited to distributed filesystems. OTOH, I don't think putting complex transactions at that level is a good choice. There's enough innate complexity there already. Adding transactions there just increases inertia, and if filesystems offered better control over ordering/durability the transaction parts could be implemented in a layer above. [1] https://www.usenix.org/system/files/conference/fast17/fast17_pillai.pdf https://www.usenix.org/system/files/conference/fast17/fast17...