Live data from Hacker News

⁠Btrfs has been deprecated in RHEL

access.redhat.com

291–300 of 352 posts

Re: ⁠Btrfs has been deprecated in RHEL

#291

More importantly Red Hat has deprecated FCoE in RHEL, which is big news, because at a previous $JOB they went all in on FCoE because it was supposed to be the future.

We've been big Cisco customers for years and ever since I saw FCoE I thought it was a disaster. All of the DCB extensions that had to go into ethernet to get it to work was such an ugly mess. It was just too complicated compared to alternatives, and iSCSI got a free ride on all that work (ethernet pause, flow control, etc) and was far simpler to implement. And of course with lots of 10Gb options with iSCSI offload, i…

Completely agreed, but it is something that Cisco was still pushing fairly heavily alongside their partners. Various different vendors bought into it, and it was deployed heavily in various different MSP's.

The complexity of FCoE is staggering, and the configuration required across all the different moving pieces to make it a success made things even more difficult!

Re: ⁠Btrfs has been deprecated in RHEL

#292
post #124

Earlier quoted context omitted.

Ouch? What's the replacement then? ISCSI, or going back to FC? Or is everything cloud something these days? :)

Yeah iSCSI and NFS. Also affecting this is the huge growth in "Hyperconverged Infrastructure" (HCI).

Hyperconverged Infrastructure is definitely eating a lot of the traditional storage vendors lunches. Using Ubuntu with JuJu/Ceph/OpenStack all on the same servers provides plenty of power while reducing costs.

Even VMWare has come on board with vSAN which pushes out vendors like EMC/NetApp because you no longer need them when you can just create it against your existing hypervisors. Sure you can run one or two less VM's on it, but you have less cost overall.

Re: ⁠Btrfs has been deprecated in RHEL

#293
post #261

Earlier quoted context omitted.

Oracle has essential control of both "nextgen" filesystems that should be used in Linux - as Sun, they developed and licensed ZFS, and they are the chief contributors of BtrFS. Their refusal to release ZFS under a license that is compatible with the GPL is keeping it out of Red Hat's distribution. This move by Red Hat must be seen as a provocation of Oracle, to force either greater cooperation and compliance in produ…

Oracle uses RHEL for their Unbreakable Linux [0] distribution. The least thing they can do is open up ZFS for the Linux community. [0] - https://linux.oracle.com/

Seconded. I am in absolute agreement.

Re: ⁠Btrfs has been deprecated in RHEL

#294
post #124

More importantly Red Hat has deprecated FCoE in RHEL, which is big news, because at a previous $JOB they went all in on FCoE because it was supposed to be the future.

Ouch? What's the replacement then? ISCSI, or going back to FC? Or is everything cloud something these days? :)

iSCSI off-load that is available on a variety of network cards, along with network policies that are similar to FCoE (never drop a packet) allow you to get the same speed/reliability as FCoE for a lot less.

FCoE requires that the networking gear drops only one packet in 10 million or something like it, if you can make the same guarantees for iSCSI, it is for all intents and purposes the same thing. With iSCSI off-load it is even better.

iSCSI also runs across your existing network stack, and doesn't require purchasing special equipment and is better supporter across a variety of different vendors, thereby making it easier to find the gear with the features you need, rather than settling for something that supports FCoE.

Re: ⁠Btrfs has been deprecated in RHEL

#295
post #31

That's too bad. The subvolume [0] features were an interesting paradigm. Kind of let you have a virtual filesystem-within-a-filesystem. [0] https://en.wikipedia.org/wiki/Btrfs#Subvolumes_and_snapshots

It's certainly interesting, but if you look at the ZFS design they were inspired by, they got a lot wrong. Some points to consider:

With ZFS, you have a hierarchy of datasets. These inherit properties from their parents, and while the mountpoints can also mimic this hierarchy, the mountpoint property can be set independently. Btrfs couples the two concepts, forcing subvolumes to be in a specific place in the actual filesystem; zfs datasets in comparison are purely metadata and are for organisation and administration, not direct use in the filesystem hierarchy.

ZFS snapshots are read-only, and clones of these snapshots are datasets in the hierarchy. Btrfs snapshots are read-write by default, which in some ways defeats the point of a point-in-time snapshot. You can also make changes to a ZFS clone and later promote it to replace the original dataset. Likewise rollbacks. Btrfs makes no provision for doing either; you have to delete the original and then rename the snapshot, which isn't atomic. ZFS' metadata preserves all relations between datasets, snapshots and clones.

The ZFS way of doing things makes things safe and accessible for system administration. There's no way to confuse the origin of a snapshot because it's tied to a parent dataset. Likewise clones of snapshots, unless you deliberately choose to break the link. The Btrfs way looks superficially nicer, but in practice is much less flexible, and potentially more dangerous since you don't have the ability to audit what came from where and when. Btrfs snapshot performance is also abysmal. ZFS handles snapshots simply by recording the transaction ID, which makes them really lightweight (and it also provides "bookmarks" which are even lighter weight). ZFS keeps the referenced blocks in deadlists, and its performance is excellent (compare how fast snapshot deletion is between the two). ZFS also allows delegating permissions to perform snapshot, clone, rollback etc. to normal users; I'm unware of Btrfs allowing such delegation--some operations can be performed like snapshotting, but not deletion, while ZFS permits this all to be configured transparently.

Re: ⁠Btrfs has been deprecated in RHEL

#296

Earlier quoted context omitted.

Hi. Did you notice that the official description of RAID-1 is "Mostly working"? Are you aware if one of your drive fails, you have one chance to re-mirror it, before the remaining drive can no longer be mounted read-write and you need to dump the filesystem and re-create from scratch?

RAID1 meaning you get one chance. Just move to RAID10 if you're worried. (/s)

It has exactly the same bug with RAID10.

Re: ⁠Btrfs has been deprecated in RHEL

#297

I am as happy as anyone that XFS is finally getting the position of honor it deserves on enterprise Linux (something like 15 years later than it should have, grumble grumble) but it doesn't really take the place of what btrfs was trying to do. Only ZFS is in a position to do that. I wonder if there are any plans for supporting the native port on RHEL.

Anecdote time: Last month I had an XFS volume fail on me. It got some sort of internal inconsistency and refused to work (all fs calls returned errors until I unmounted). This is where I discovered that XFS still has extremely poor recovery tools. xfs_repair will complain if there is a journal present and tell you to mount the fs to replay the journal. But mount would refuse, saying the fs was inconsistent. So the on…

Yikes. That's unnerving to read. Were you able to create a bug report? Was there any other related issue like an underlying storage controller messing up?

Re: ⁠Btrfs has been deprecated in RHEL

#298
post #214

Considering the size of disks now-a-days, the chance of bit rot is high. And (I don't have the original source) on SSD, bit rots probability is higher still. So... ZFS and BTRF have meta-data as well as data checksumming. From what I've read, XFS may have metadata checksumming, but not on the data side of things. I consider checksumming important. Do others? What is the solution? What other file systems offer that so…

There are many different ways that storage can be layered, and depending on your use case, you can put various advanced features (snapshots, checksum/data integrity, encryption, etc.) functionality in different places in the storage stack. You can put functionality the block device layer (e.g., lvm, dm-thin, dm-verity), you can put functionality into the file system, you can put functionality into the cluster filesys…

Given a stock (or additional packages?) RHEL 7.4 install on non-clustered storage, what would be the best combination to detect & correct bitrot at the filesystem and lower level?

Re: ⁠Btrfs has been deprecated in RHEL

#299

I don't think this matters much. If you want btrfs, you'll likely be able to get kernel module from EPEL even if they'll stop shipping it. It's like deprecated and unsupported LXC which could be used just fine and which doesn't have usable replacements.

> deprecated and unsupported LXC

Where did you hear this? This is news to me. https://linuxcontainers.org/ and https://github.com/lxc/lxc both seem active and supported by Canonical to me. The only deprecated project by them is listed to be CGManager.

Re: ⁠Btrfs has been deprecated in RHEL

#300

I have used Btrfs in production and I would say it's great. It's super easy to just add an extra EBS volume and attach to a Btrfs volume and now you have more disk space. Performance is good enough for me as well, I used it as storage for InfluxDB and Docker. Luckily this is only Redhat, not Btrfs itself.

How much did you deal with snapshots? Because I've had crippling performance problems stemming from them. Even something as simple as having 90 daily snapshots and deleting the oldest few can cause trouble, where the filesystem does not respond to any requests for multiple seconds. And that's on an SSD. I don't remember if it was deleting snapshots or running balance, but I've had Btrfs on a hard drive not respond to…

Not only that but in conjunction with journald you can achieve amazing disk space leaks that cannot be repaired easily without losing data.
Post reply on HN