Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

⁠Btrfs has been deprecated in RHEL

access.redhat.com

Post reply on HN
Print view View original

301–310 of 352 posts

Re: ⁠Btrfs has been deprecated in RHEL

#301

Post by _wxyv »

zerd wrote: post #281
mrob wrote: post #247

Earlier quoted context omitted.

Linux 4.12 introduced dm-integrity, which adds integrity checking at the block device level, so it will work with any file system: https://gitlab.com/cryptsetup/cryptsetup/wikis/DMIntegrity

One good thing about ZFS integrity checking is that when it finds an error it can repair the bit rot from another disk if you have parity or mirroring. Can dm-integrity do that?

dm-integrity will only operate on a single disk so no, not on its own.

It does however return an error if the integrity check fails, so if you put mdadm on top, mdadm can repair the erroneous block. I've tested this and am currently running it on a 32TB array.

Re: ⁠Btrfs has been deprecated in RHEL

#302

Post by fundabulousrIII »

headlands wrote: post #47

The default file system for the root partition of SUSE Enterprise Linux is Btrfs. So RHEL have stopped supporting it. It is the only filesystem that implements many of the features found in ZFS.

It's also buggy as hell and though I've used SuSE for 17 years I almost stopped this year due to btrfs. Terrible decision from SuSE: but they aren't the company they used to be.

Re: ⁠Btrfs has been deprecated in RHEL

#303

Post by rob-olmos »

willglynn wrote: post #279
usefulcat wrote: post #193

Earlier quoted context omitted.

Yes it can detect errors, but it can't continue to function correctly (read: return the correct data) because it doesn't know which copy of the differing data is damaged because it doesn't have checksums. Moreover, if it doesn't always read both copies of the data (which it may well not, for performance reasons), then you have the possibility of silently propagating damaged data to all mirrors in the case that damage…

Yep. "What happens if you read all the disks successfully but the redundancy doesn't agree?" is a great question. Mirrors and RAID5: there's obviously no way that `md` software RAID can help, since it doesn't know which is correct. What about RAID6 though? Double parity means `md` would have enough information to determine which disk has provided incorrect data. Surely it does this, right? Wrong. In the event of any…

That's incredible! Thanks for the insight.

Any recommendations for detecting/correcting bitrot with RHEL 7.4 at the filesystem or lower levels?

Re: ⁠Btrfs has been deprecated in RHEL

#304

Post by tylerjd »

rleigh wrote: post #295
sparky_ wrote: 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 f…

Are you trying to say that BTRFS is supposed to compete feature-to-feature with ZFS? It's not. https://lwn.net/Articles/342892/

>I had a unique opportunity to take a detailed look at the features missing from Linux, and felt that Btrfs was the best way to solve them.

>From other points of view, they are wildly different: file system architecture, development model, maturity, license, and host operating system, among other things

-------------------------------

>Btrfs snapshots are read-write by default, which in some ways defeats the point of a point-in-time snapshot.

Yes, and have the option of being read only for your temporal "in place" snapshots. But if I want to clone a container for instant use (as LXC or Docker does), then the RW snapshots make sense. Btrfs doesn't make a distinction between a Clone and Snapshot, they are one and the same with a flag.

> but in practice is much less flexible

Tell me more how I can mix disks of differing size in RAID on ZFS

> There's no way to confuse the origin of a snapshot because it's tied to a parent dataset

There's no confusing to the origin of my sanpshots. `btrfs subvolume list -q` shows the ancestral parent as well as the subvolume it's located in, example:

  ID 6442 gen 50527 top level 751 parent_uuid 0f4442f8-6363-6944-be8d-e2b45d809352 path .snapshots/321/snapshot
> some operations can be performed like snapshotting, but not deletion

See user_subvol_rm_allowed mount option, available since Kernel 3.0

It's like comparing a car and a truck, they both have four wheels, transport passengers and cargo, and have an engine. Just because a truck runs on diesel does not make the fact that the car running on gas "wrong". Due to its fundamentally different implementation, the way the filesystem works is also different.

Yes ZFS has many more features, has been in development longer, and probably more "production ready" than BTRFS. But ZFS is not GPL compatible. And BTRFS doesn't require it's own separate cache that is apart from the normal filesystem cache.

Re: ⁠Btrfs has been deprecated in RHEL

#305

Post by chasil »

chasil wrote: post #261
pgaddict wrote: post #255

Earlier quoted context omitted.

I think a natural follow-up question is "Why Red Hat does not have engineers to support btrfs?" That is, if the lack of engineers is a symptom, what is the cause? I'm pretty sure, had RH wanted they could either hire or assign engineers to maintain the btrfs code, take care of patches from upstream, etc. So why didn't that happen? I wonder what is your opinion on that. I see a bunch of possibilities (not necessarily…

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…

This will particularly impact the "Red Hat Compatible Kernel" (RHCK) that is shipped by Oracle Linux.

https://docs.oracle.com/cd/E37670_01/E57668/html/ol_kern_65r...

Assuming that RHEL v8 strips BtrFS, Oracle's RHCK will have to add support back in, and thus no longer be "compatible." Without that support, some filesystems will fail to mount at boot. In-place upgrades from v7 to v8 will be problematic.

Oracle has worked very hard to maintain "compatibility" with Red Hat, even going so far as to accept MariaDB over MySQL. Their reaction to the latest "poison pill" will be interesting.

Re: ⁠Btrfs has been deprecated in RHEL

#306

Post by beagle3 »

Btrfs brings IMO too little to the table, considering that ZoL is quite mature; It always seemed to me like it's the "we can't have ZFS so..." solution, but unlike Gnome (being the "can't have KDE" solution), it does not yet deliver, after a long long time.

The next fs to make a difference, post ZFS, is likely HAMMER2[0] - it's supposedly already stable for single node use (the ZFS / XFS / ext4 use case), and is advancing towards the multinode-at-the-underlying-fs-level, a first.

[0] https://gitweb.dragonflybsd.org/dragonfly.git/blob_plain/HEA...

Re: ⁠Btrfs has been deprecated in RHEL

#307

Post by aeorgnoieang »

gigatexal wrote: post #283
aeorgnoieang wrote: post #244

Earlier quoted context omitted.

> But nested mirrors still suffer from the same issue of losing a drive and you lose everything. Are you referring to mirroring a volume or dataset on a single disk? Why would you want to do that instead of mirroring among multiple drives?

how would you set up a large pool? two sets of say 5 disks in a mirror raidz1 would still fail if a disk in one set failed and a disk in the other set failed. I guess you could do a stripe setup of 5 sets of 2 disks in mirrors. Still it seems wicked risky to me. I do agree though mirroring has been the best for speed but a lot of that changes with nicer SSDs especially NVMe ones.

I was curious about what a "nested" mirror is really. What exactly is nested?

I'd setup a large pool with mirror vdevs, i.e. n sets of 2 disks per mirror.

My half-remembered reasoning was that backups manage the risk you'll lose data. But replacing a disk in a mirror vdev is much easier, and faster, than doing so with RAIDZ.

The risk of RAIDZ is that resilvering impacts multiple vdevs, is much more intensive than a simple mirror resilvering, and thus the probability that additional drives will fail is much higher.

Here's a blog post that I definitely read the last time I was reading up on this:

- [ZFS: You should use mirror vdevs, not RAIDZ. – JRS Systems: the blog](http://jrs-s.net/2015/02/06/zfs-you-should-use-mirror-vdevs-...)

Re: ⁠Btrfs has been deprecated in RHEL

#308

Post by rodgerd »

jdmulloy wrote: post #233
rodgerd wrote: post #100

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?

What do you mean by one chance to re-mirror? Does this mean that if the resilver fails you can't try it again? Is this documented? With ZFS or regular RAID as long as you have one good disk in the mirror you can resilver, is this not the case for BTRFS? If so this is quite disappointing. There's a reason my server is running ZFS on FreeBSD. I also love jails, which let me have as many virtual servers as I want withou…

> Does this mean that if the resilver fails you can't try it again? Is this documented?

It's documented on the status Wiki. RAID 1 is "mostly working". If a mirror drops to having one disk, you can mount it once as a read-write volume (required for resilvering); after that, you have to trash it and start again.

Re: ⁠Btrfs has been deprecated in RHEL

#309

Post by rodgerd »

viraptor wrote: post #112
rodgerd wrote: post #100

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?

That's just how raid mirroring works. Now sure why you mention it specifically for btrfs?

No, it isn't. You can run a ZFS VDEV or a Linux mdraid as a single-disk RAID 1 unit until the remaining disk fails. You have an arbitary number of reboots/remounts to fix the problem.

Re: ⁠Btrfs has been deprecated in RHEL

#310

Post by aeorgnoieang »

gigatexal wrote: post #283
aeorgnoieang wrote: post #244

Earlier quoted context omitted.

> But nested mirrors still suffer from the same issue of losing a drive and you lose everything. Are you referring to mirroring a volume or dataset on a single disk? Why would you want to do that instead of mirroring among multiple drives?

how would you set up a large pool? two sets of say 5 disks in a mirror raidz1 would still fail if a disk in one set failed and a disk in the other set failed. I guess you could do a stripe setup of 5 sets of 2 disks in mirrors. Still it seems wicked risky to me. I do agree though mirroring has been the best for speed but a lot of that changes with nicer SSDs especially NVMe ones.

A Reddit post about that blog post in my other reply:

- [You should use mirror vdevs, not RAIDZ. : DataHoarder](https://www.reddit.com/r/DataHoarder/comments/2v0quc/you_sho...)

Post reply on HN