On Fri, Aug 11, 2017 at 12:12 PM, Warren Young <warren at etr-usa.com> 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