Yes, the low level format for btree nodes/btree keys isn't changing, and the fact that it's a database does ease a lot of backwards and forwards compatibility i

Yes, the low level format for btree nodes/btree keys isn't changing, and the fact that it's a database does ease a lot of backwards and forwards compatibility issues - for example, most key types can have new fields appended and old versions will just ignore the new field. But schema changes can still be pretty impactful. The big on disk format changes were: - accounting rewrite in 6.11, which switched from a high performance, but complex and difficult to extend mechanism where accounting was stored in memory with percpu counters and then bundled up in each journal entry, to storing them in btree keys and journalling them as deltas. The runtime code was so vastly different that it just wasn't possible to keep writing out the old accounting without retaining all of the old code side by side with the new code - it would have been really gross. - backpointers change in 6.14, for fsck scalability improvements This one would have been possible to do without rewriting all the backpointers, but that still would've had severe downsides. The main option would've meant permanently inflating the size of the backpointers btree by ~20%, IIRC, and backpointers are almost half of all metadata on a typical filesystem. There were ways to get around that, but they would've added a lot of complexity that we would've had to carry around forever. But those are exactly the sorts of things the experimental phase is for - getting it on more and bigger systems and seeing what shakes out and finding out what we still need.