117 ms·

I think Red Hat ultimately decided btrfs is not going to go anywhere, and ZFS is unfortunately a non-starter for licensing reasons, so from their perspective it

I think Red Hat ultimately decided btrfs is not going to go anywhere, and ZFS is unfortunately a non-starter for licensing reasons, so from their perspective it really doesn't matter how good it is. 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.

cmurf 7y ago
Red Hat doesn't have developers to support Btrfs, and it takes a lot of support if you're going to depend on constant backporting of fixes and features. All the major work on Btrfs happens upstream and RHEL kernels just aren't anywhere close to that. So to support this in an enterprise context with support plans, you'd have to have many knowledgable Btrfs developer and support staff. 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.
- danieldk 7y ago
  Red Hat doesn't have developers to support Btrfs, and it takes a lot of support if you're going to depend on constant backporting of fixes and features. 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.
  - chousuke 7y ago
    I suppose requiring a transition might be the problem in the first place. XFS and LVM are things that are in use now. Though they might not be the most performant or the most convenient at this time, it makes for a strong strategy if you can bring in new features without requiring users to switch over to something completely new.

cmurf 7y ago

Red Hat doesn't have developers to support Btrfs, and it takes a lot of support if you're going to depend on constant backporting of fixes and features. All the major work on Btrfs happens upstream and RHEL kernels just aren't anywhere close to that. So to support this in an enterprise context with support plans, you'd have to have many knowledgable Btrfs developer and support staff. 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.

danieldk 7y ago
Red Hat doesn't have developers to support Btrfs, and it takes a lot of support if you're going to depend on constant backporting of fixes and features. 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.
- chousuke 7y ago
  I suppose requiring a transition might be the problem in the first place. XFS and LVM are things that are in use now. Though they might not be the most performant or the most convenient at this time, it makes for a strong strategy if you can bring in new features without requiring users to switch over to something completely new.