BTRFS is developed since 2007 ...
... and Red Hat decides to reimplement this kind of pooled storage filesystem again with XFS on LVM now called Stratis ... not very bright.
BTRFS is developed since 2007 ...
... and Red Hat decides to reimplement this kind of pooled storage filesystem again with XFS on LVM now called Stratis ... not very bright.
I suppose the benefit of using XFS and LVM is that they're both very well understood and widely used technologies. Sometimes incremental evolution is all you need.
I'm following the development with interest, because I think the approach has merits. Dave Chinner's talk about teaching XFS how to do snapshots and subvolumes was particularly interesting. The gist of it, as far as I understand, is that XFS can pretty much do those things already, but it needs better integration for performance and usability.
Obviously it is going somewhere, upstream is very active, and SUSE uses it by default everywhere both enterprise and openSUSE. And they have the developers to support it. Facebook uses Btrfs quite a lot in production both servers and desktops.
Given how many kernel developers and filesystem developers they have, it would not be hard for them to hire btrfs developers or ask some of their kernel developers with a background in file systems to specialize in btrfs. I think the reasons are different: either it's because they have a lot of XFS developers on staff, fighting a transition to btrfs nail and tooth; or they simply believe that btrfs cannot be made good enough to support their enterprise developers within a reasonable time frame.