BTRFS deprecated on Red Hat Enterprise 7

[m0nkey_]

I can't say this is surprising. Now, if only we could convince Red Hat to adopt ZFS instead? ;)

The Btrfs file system has been in Technology Preview state since the initial release of Red Hat Enterprise Linux 6. 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.

https://access.redhat.com/documenta...4_Release_Notes-Deprecated_Functionality.html

 

[danb35]

Must be a mistake. We know it's safe, stable code with a lot of big companies behind it.

 

[nightshade00013]

Sadly even though ZFS on linux is available I doubt Red Hat will use it and deal with the license clash like Ubuntu has been going through.

 

[Ericloewe]

So, what are they going to do? Pretend that traditional filesystems are fine for enterprise use?

 

[nightshade00013]

That or recommend hardware raid for enterprise situations.

 

[Ericloewe]

That or recommend hardware raid for enterprise situations.

Which solves next to nothing.

 

[nightshade00013]

Yep, but they don't seem to want to create a new file system or want to put the time into strengthening something like BTRFS.

It's the standard well we will do the bare minimum to make some money. Thankfully from what I have seen from the iXsystems guys that has not been the case. Especially after devoting a ton of time to FreeNAS 10/Corral and then killing it when the release showed that it was not a viable product.

 

[Stux]

So, what are they going to do? Pretend that traditional filesystems are fine for enterprise use?

Run FreeBSD in a VM and serve iscsi back out?

;)

 

[nightshade00013]

Run FreeBSD in a VM and serve iscsi back out?

;)

Hmmm does a VM under redhat have passthrough? Maybe Virtualize both RedHat Enterprise and FreeBSD, and then serve the iSCSI out for storage or just run FreeBSD and Virtualize RedHat Enterprise?

 

[Stux]

Hmmm does a VM under redhat have passthrough? Maybe Virtualize both RedHat Enterprise and FreeBSD, and then serve the iSCSI out for storage or just run FreeBSD and Virtualize RedHat Enterprise?

https://www.servethehome.com/the-proxmox-ve-kvm-based-all-in-one-freenas/

 

[nightshade00013]

https://www.servethehome.com/the-proxmox-ve-kvm-based-all-in-one-freenas/

Yep there we go, now we have fixed the Red Hat Enterprise storage problems with a safe and secure file system. I wonder how much we can charge them for it....

 

[Omega]

https://www.phoronix.com/scan.php?page=news_item&px=Stratis-Red-Hat-Project

 

[Stux]

https://www.phoronix.com/scan.php?page=news_item&px=Stratis-Red-Hat-Project

So, basically, they've decided to re-implement something just like ZFS from scratch. That sounds like a fun ride. See you in half a decade.

 

[Omega]

Well, seems more userspace tools on top of existing things:

Rather than writing a new VMF from scratch, Stratis proposes to satisfy VMF-like require-
ments by managing existing technologies on behalf of the user, so that users can manage their
storage using high-level concepts like “pool” and “filesystem”, and remain unconcerned with the
sizable stack of layered blockdevs doing all the work under the covers.

https://stratis-storage.github.io/StratisSoftwareDesign.pdf

Feature parity with ZFS in version 3.0 :)

 

[elettronik]

Looking at document toc you linked:

Code:

9 D-Bus Programmatic API

So systemd could be a fs manager too. :):):):):):):)

 

[Arwen]

I used BTRFS at home for a few years. It seemed stable. I was even able to use it for alternate boot environments via snapshots.

Initially it's boot volume naming on the kernel line in Grub had to use the volume's number. This was annoying since I had to look up the number after I creating the writable snapshot. Then update Grub, as well as both copies of the /etc/fstab. Later they fixed that, allowing the name of the file system. That meant I could update the parent /etc/fstab before the snapshot, and the changes were passed on.

Another thing that BTRFS did not have then, was data duplication ala copies=2 like ZFS has. BTRFS does now, but I have since moved all 3 of the Linux boxes to ZFS. Plus, I was able to use real ZFS mirroring on 2 of them now, (bought 2nd disk), and mirror across 2 partitions on my laptop.

The thing that caused me to move my Linux boxes to ZFS was that in 2013 ZFS on Linux became pretty stable. And that BTRFS still was not considered stable. I had not lost data by then, but I wanted stability and reliability. Plus, BTRFS is Linux only and not likely supported widely, (like Android or embedded devices).

In my opinion, BTRFS should have had a fork for development. The RAID-5/6 thing should be a development fork, and the simple Mirroring / RAID-1 should have been worked towards stablization. And new, (and stable), features from the development set should then be back ported. Keep the production version of BTRFS stable and reliable. Most people saw that there was so much to be done, that they would not consider BTRFS, even in a simple Mirror configuration.

Today, I see that BTRFS is basically going into wonderland. They started adding COW to files. Meaning you can create a new file that is a the same as an existing file, but on changes to either, it will copy on write. Weird. See;

https://en.wikipedia.org/wiki/Btrfs#Cloning

 

[Stux]

In my opinion, BTRFS should have had a fork for development. The RAID-5/6 thing should be a development fork, and the simple Mirroring / RAID-1 should have been worked towards stablization. And new, (and stable), features from the development set should then be back ported. Keep the production version of BTRFS stable and reliable. Most people saw that there was so much to be done, that they would not consider BTRFS, even in a simple Mirror configuration.

Totally agree. You have to get the basics right, and keep the unstable/experimental features in the experimental branch.

Today, I see that BTRFS is basically going into wonderland. They started adding COW to files. Meaning you can create a new file that is a the same as an existing file, but on changes to either, it will copy on write. Weird. See;

https://en.wikipedia.org/wiki/Btrfs#Cloning

I think APFS has that too... Makes a bit of sense for Apple though... they can just tie 'cp' and all the OS and GUI Copy functions to "clone" under the hood. They demonstrated this actually.

Makes 'cp' as fast as an 'mv'

Something that I think ZFS should actually have... at least in a dataset, because that'd be a real trick if it wasn't :)

Another feature I thought was neat was the In-place ext2/3/4 conversion, with rollback. Of course, its another "never actually stable" feature.

 

[Ericloewe]

Something that I think ZFS should actually have... at least in a dataset, because that'd be a real trick if it wasn't :)

Of course it does, see section 19.4.6 of the FreeBSD manual:

https://www.freebsd.org/doc/handbook/zfs-zfs.html

 

[Stux]

Of course it does, see section 19.4.6 of the FreeBSD manual:

https://www.freebsd.org/doc/handbook/zfs-zfs.html

Not cloning datasets. But cloning files *inside* datasets.

 

[Ericloewe]

Not cloning datasets. But cloning files *inside* datasets.

Isn't that what you were hoping for in your less pie-in-the-sky scenario?

As for cloning files, I can imagine it being one of those features that would be relatively easy to implement, but that nobody cares about enough to work on.