On Fri, Aug 11, 2017 at 12:12 PM, Warren Young <warren@xxxxxxxxxxx> wrote:
> I rather doubt btrfs will be compiled out of the kernel in EL8, and even if it is, it’ll probably be in the CentOSPlus kernels.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html
"Red Hat will not be moving Btrfs to a fully supported feature and it
will be removed in a future major release of Red Hat Enterprise
Linux."
Unless the EL8 kernel is based on a regularly maintained (by Btrfs
upstream) longterm kernel such as 4.9 at the oldest, then it's way too
much work to backport Btrfs fixes to older kernels. Red Hat is clearly
saying they're removing it. And I expect CentOS won't have the
resources to do this work either. Either they get it for free from
upstream by using an longterm kernel, or gets removed.
But we'll just have to see I guess.
All I can say is that Fedora is keeping it and still has high hope for
Btrfs users, experts, contributors, developers, etc. That's in
Fedora's interest.
> But will you be able to install EL8 onto an existing XFS-formatted boot volume and mount your old btrfs data volume? I guess “yes.”
I guess no, based on the word "removed"
>
>>> removing btrfs alltogether would be taking living in the past too
>>> many steps too far.
>
> The Red Hat/Fedora developers are well aware that they started out ~7 years behind when they pushed btrfs forward as a “technology preview” with RHEL 6, and are now more like 12 years behind the ZFS world after waiting in vain for btrfs to catch up.
>
> Basically, Stratis is their plan to catch up on the cheap, building atop existing, tested infrastructure already in Linux.
Well they have no upstream Btrfs developers. SUSE has around a dozen.
Big difference. And then Red Hat has probably at least a dozen
developers involved in md, device-mapper, LVM, and XFS. So it makes
sense if they are hedging their bets, they're going to go with what
they already have resources in.
Also, I see it as tacit acknowledgement that Btrfs is stable enough
that it's silly to call it a technology preview, but not so stable
they can just assume it will work on its own without having
knowledgeable support staff and developers on hand, which they don't.
So it seems to me they pretty much had to cut off Btrfs, but I don't
know if this was a technical decision or if it was a recruiting
problem or some combination.
>
> My biggest worry is that because it’s not integrated top-to-bottom like ZFS is, they’ll miss out on some of the key advantages you have with ZFS.
>
> I’m all for making the current near-manual LVM2 + MD + DM + XFS lash-up more integrated and automated, even if it’s just a pretty face in front of those same components. The question is how well that interface mimics the end user experience of ZFS, which in my mind still provides the best CLI experience, even if you compare only on features they share in common. btrfs’ tools are close, but I guess the correct command much more often with ZFS’ tools.
It always comes down to edge cases. XFS folks are adding in CoW for
reflinks, which Btrfs has had stable for years, practically from the
very beginning, and they have had plenty of problems with mainly one
developer working on it, it's not a default feature yet. LVM thin
provisioning likewise uses CoW, they've had plenty of problems with
fragmentation that are not all that different from the user experience
anyway, than when Btrfs experiences massive free space fragmentation.
So... these are really hard problems to fix and I think people really
do underestimate still the brilliance of the ZFS development team and
the hands free approach they were given for development.
And then I also think we don't recognize how lucky we are in free
software to have so many options to address myriad workloads and use
cases. Yes it's tedious to have so many choices rather than a magic
unicorn file system that's one size fits all. But I think we're more
lucky than we are cursed.
>
> That latter is an explicit goal of the Stratis project. They know that filesystem maintenance is not a daily task for most of us, so that we tend to forget commands, since we haven’t used them in months. It is a major feature of a filesystem to have commands you can guess correctly based on fuzzy memories of having used them once months ago.
Yeah and frankly a really constrained feature set that doesn't account
for literally everything. LVM's fatal flaw in my view is as an
anaconda dev once put it, it's emacs for storage. It's a bottomless
rabbit hole. Badass, but it's just a massive "choose your own
adventure" book.
Btrfs isn't magic but it does do a lot of things really right in terms of Ux.
'btrfs device add'
'btrfs device delete'
That does file system resize, including moving extents if necessary in
the delete case, and it removes the device from the volume/array and
wipes the signature from the device. Resize is always online, atomic,
and in theory crash proof. There's also the seldom discussed seed
device / overlay feature, useful for live media that's substantially
simpler to implement and understand compared to dm - and it's also
much more reliable. The dm solution we currently have for lives will
eventually blow up without warning when it gets full and the overlay
is toast.
https://github.com/kdave/btrfs-wiki/wiki/Seed-device
--
Chris Murphy
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
