Re: Redhat dropping support for BTRFS

[Steven Pritchard <steve@silug.org>]

On Sat, Aug 12, 2017 at 03:18:11PM -0400, Nathaniel Reindl wrote:
> On Sat, Aug 12, 2017, at 13:26, Steven Pritchard wrote:
> > Maybe if the rate of change in the btrfs code drops and the filesystem
> > starts to prove itself, Red Hat will add it back in as a technology
> > preview in RHEL 8.x (where x > 1).
> 
> OTOH, the strategy they intend to employ in light of this, in conjunction with the historical need to toil to manage all of the various storage components in RHEL in an additive manner, is a storage system running almost completely in ring 3 called Stratis. See <https://stratis-storage.github.io/StratisSoftwareDesign.pdf>. It should be first appearing in Fedora 28.
> 
> In general, I feel I can get more behind something like that where the code that runs in ring 0 is either extremely minimal or is a stable module that doesn't see a lot of churn or a lot of defects.

So I'll admit to being lazy and not looking at the PDF you linked to,
but I would be willing to bet that Stratis doesn't solve the major
problem that ZFS and btrfs solve: detecting bit rot and other sources of
corrupt data on disk.  I understand there is some work being done on
adding checksum support to device-mapper, which could conceivably solve
the problem for all users, but I don't know how close that is to being
readily available.

> Ultimately, at the end of the day, I'm not particularly sure that it's
> uncouth for a systems distribution integrator to take a separate Linux
> kernel package and a separate ZFS package—barring technological
> restrictions—and combine them together with the functionality that
> would satisfy business need. GPL incompatibility does not imply
> non-free, and licensing a Linux distribution as a whole, complete work
> per the legal definition seems ludicrous to me. —n

Yeah, I agree...  I'm not entirely convinced that adding the packages
from zfsonlinux.org to RHEL would be any kind of a licensing issue, but
I am not a lawyer...

-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.