
⁠Btrfs has been deprecated in RHEL - alrs
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
======
josefbacik
People are making a bigger deal of this than it is. Since I left Red Hat in
2012 there hasn't been another engineer to pick up the work, and it is _a lot_
of work.

For RHEL you are stuck on one kernel for an entire release. Every fix has to
be backported from upstream, and the further from upstream you get the harder
it is to do that work.

Btrfs has to be rebased _every_ release. If moves too fast and there is so
much work being done that you can't just cherry pick individual fixes. This
makes it a huge pain in the ass.

Then you have RHEL's "if we ship it we support it" mantra. Every release you
have something that is more Frankenstein-y than it was before, and you run
more of a risk of shit going horribly wrong. That's a huge liability for an
engineering team that has 0 upstream btrfs contributors.

The entire local file system group are xfs developers. Nobody has done serious
btrfs work at Red Hat since I left (with a slight exception with Zach Brown
for a little while.)

Suse uses it as their default and has a lot of inhouse expertise. We use it in
a variety of ways inside Facebook. It's getting faster and more stable,
admittedly slower than I'd like, but we are getting there. This announcement
from Red Hat is purely a reflection of Red Hat's engineering expertise and the
way they ship kernels, and not an indictment of Btrfs itself.

~~~
feld
The problem is that Redhat and others are refusing to challenge the norm and
break away from the "freeze the release; backport fixes" mantra.

Stop backporting fixes. You're forking the codebase.

Ship exactly what upstream provides.

Teach upstream projects how to do better release engineering if they're
abandoning major releases to early or breaking API/ABI in a minor release.

Stop backporting fixes. You're forking the codebase.

edit: also stop incorrectly backporting security fixes and creating new CVEs.
Seriously. Stop it.

~~~
krylon
> the "freeze the release; backport fixes" mantra.

For many customers of Red Hat, that mantra is the very reason they use RHEL in
the first place.

~~~
digi_owl
Indeed. Or they would have stuck to using Windows, or some commercial Unix.

Sadly i feel that more and more upstream wants it both ways, be able to push
their latest and shiniest, and keep ignoring any need for interface stability
etc.

Frankly i suspect the end result of the likes of Flatpak will be that upstream
push whole distros worth of bundled libs, just so they don't have to consider
interface stability as they pound out their shinies in their best "move fast
and break things" manner.

------
justin66
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.

~~~
mrweasel
Redhat hasn't been on the best of terms with Oracle, so I suspect that they
want to stay clear of ZFS. It does however leave Redhat without a more modern
feature rich filesystem.

Perhaps Redhat could help to develop snapshots on XFS. It's not the only
feature XFS is missing, but it's a start.

~~~
cyphar
> Perhaps Redhat could help to develop snapshots on XFS. It's not the only
> feature XFS is missing, but it's a start.

Upstream has been working on adding more btrfs-like features to XFS, but I
believe that RHEL encourages using devicemapper snapshots (which you then
format with XFS).

~~~
2ion
> Upstream has been working on adding more btrfs-like features to XFS, but I
> believe that RHEL encourages using devicemapper snapshots (which you then
> format with XFS).

Exactly, mountable and mergable snapshots have been supported by a
LVM/devicemapper stack for a long time.

~~~
rbanffy
It's still a bit more involved than the transparent snapshots ZFS and, to a
lesser degree, BtrFS offer. I'm not happy with this and sincerely hope this
position changes in the future.

------
stargrazer
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 sort of capability?

Snapshotting is a second go-to function. Particularly when it is integrated
into the LXC container creation process. (There was a comment elsewhere here
which said LXC is on it's way out.... huh? what?)

~~~
ars
Use mirror raid and have mdadm do a full disk compare/check every month (this
is the default on Debian).

Additionally use smartmontools and configure it to do a short self test each
night, and a long self test (i.e. full disk read) each week.

This will catch/flag errors early, which mdadm will then detect.

~~~
usefulcat
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 damaged data is
returned to an application and the application then rewrites said data.

Compare that to a filesystem with checksums, which, in addition to being able
to detect such a problem, could also continue to function completely correctly
in the face of it.

~~~
willglynn
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 parity mismatch, `md` assumes the data disks are
correct and rewrites the parity to match. See "Scrubbing and Mismatches"
section in `man 4 md`:

[https://linux.die.net/man/4/md](https://linux.die.net/man/4/md)

If you scrub a RAID 6 array with a disk that returns bad data, `md` helpfully
overwrites your two disks of redundancy in order to agree with the one disk
that's wrong. Array consistent, job done, data... eaten.

~~~
rob-olmos
That's incredible! Thanks for the insight.

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

------
buserror
Well I used btrfs as a root filesystem for quite a while, until I realized it
was pig slow for sync() -- I mean, it would take AGES to do and apt-get
upgrade for example. I ended up having to do some tasks using 'eatmydata' [0]
to make it all better, risking filesystem corruption in trade for speed. Also,
at the time, there was no functioning fsck.

So I moved back safely to ext4 and never looked back!

[0]:
[https://www.flamingspork.com/projects/libeatmydata/](https://www.flamingspork.com/projects/libeatmydata/)

~~~
buster
Over the recent years on every new laptop install i switched between
filesystems, so i had ext3/4, btrfs and (currently) xfs on my system. I have
to say, btrfs had the most glitches (a few years back), although it worked
ok'ish (no data loss).

Nowadays, i must say that i very much prefer a stable filesystem with as
little complicated logic as possible. I actually never use snapshots or
subtrees! I never put another disk in my laptop (where would that go?!) so i
don't need to do dynamic resizing (while online of course!). All this makes
the filesystems a lot more complex then it has to be. I've also run into
problems using ZFS on Solaris some years back which took ~2 weeks in dtracing
what the hell is going on. Of course it was related to CoW.

My lessons learned: Check your requirements. Will you really need and use
subtrees/snapshots/XYZ on your system? Will you really need to do online-
resizing? If not, just use a stable, simple filesystem. There are perfect
usecases for ZFS or btrfs. But not everyone needs the advanced features.

~~~
viraptor
> Will you really need and use subtrees/snapshots/XYZ on your system?

It's a valid question, but not the best one. Almost nobody needs snapshots.
But they make things easier. You most likely don't _need_ a journaled fs in
your laptop either (battery level notification should take care of the
issues). But it does make life better.

"Need" is not the threshold I'm interested in. Most features, I'd like. One
feature I think I do need most is scrubbing, which is still absent from most
filesystems :(

~~~
buster
"Need" as in "will you use it?". I played around with snapshots once and never
really used them. So i clearly don't have a need for them on my laptop.
Journaling on the other hand helps data safety a lot and i think it's not
overly complex. I've had data loss happing in the past before journaling, but
never again since then. So, wouldn't i need CoW for even better "data safety"?
Maybe, but since i've never experienced data loss for so many years, i don't
feel like the added complexity is worth it. On my laptop, for my usecase.

But that's only me. Your experience may differ very much :)

~~~
lomnakkus
> "Need" as in "will you use it?".

Well, many of us have experienced a botched system package upgrade or two. If
the file system supports snapshots, then the package manager could
automatically ensure fully atomic package upgrades.

That should be reason enough, I should think.

Re: The data loss issue: Yes, I've actually have XFS completely throw away a
file system upon a hard power-off + boot-up cycle. (This was _ages_ ago, I'm
sure it's improved heaps since then.)

~~~
buster
Good point. I'm using Debian as my Desktop for many years. I don't remember a
"botched" system package upgrade in the last 5 years, but i've probably
learned over years how to handle dpkg/apt.

The atomic updating is a very interesting topic and the reason why i find
ostree/guix/nixos very appealing. Note that neither ostree nor guix or nixos
make use of filesystem snapshots, afaik. OSTree even documents why it won't
use filesystem snapshots:
[https://ostree.readthedocs.io/en/latest/manual/related-
proje...](https://ostree.readthedocs.io/en/latest/manual/related-
projects/#combining-dpkgrpm-btrfslvm) Debians dpkg does not use snapshots as
well.

So, it's a definitely a nice-to-have, but not something i need, because i can
handle dpkg/apt much better then i could handle filesystem internals.

That's sort of the point: I don't want the complexity in the filesystem, but i
am fine with it in userspace. I can use snapshots on filesystem level. Or i
can use other backup tools in userspace. While it's certainly neat that the
filesystem can do that, i'm perfectly fine with handling backups on another
level.

Another example: It's certainly neat that there are a bunch of distributed
filesystems (which by the way have A LOT of complexity and often can't handle
all workloads you would expect from a filesystem). But i'd rather use either
an S3-like network storage or build a system that scales well without relying
on Ceph/Gluster/Quobyte/etc.

For example, in a hypothetical distributed system i'd rather use Cassandra and
distribute data over commodity hardware then use Ceph. I'd rather handle
problems with data persistence/replication on the cassandra level then
debugging on file system level. Especially, when Cassandra has a problem i'll
most likely be able to access all data atleast on the filesystem level. When
my filesystem is borked, i'm in a much worse situation.

~~~
lomnakkus
> So, it's a definitely a nice-to-have, but not something i need, because i
> can handle dpkg/apt much better then i could handle filesystem internals.

I don't think you're seeing my point. _You_ wouldn't have do anything -- it
would all be done automatically as long as your file system supports
snapshots.

BTW, to your "I know how to use dpkg/apt": It's not about knowledge. I could
well be said to be at an "advanced" level of expertise in system maintenance,
but "system upgrade" fuckups had nothing to do with me, but everything to with
bad packaging and/or weird circumstances such as a dist-upgrade failing midway
through because some idiot cut a cable somewhere in my neighborhood.

While Nix and the like are nice and all, they're currently suffering from a
distinct lack of manpower relative to the major distributions. They also don't
_quite_ fully solve the "atomic update" problem, but that's a tangent. Then,
OTOH, some of them have other advantages such as the easy of maintaining your
full system config in e.g. Git. Swings and roundabouts on that front. FS
support for snapshots would help _everybody_.

~~~
buster
You're absolutely right. Still, dpkg doesn't support snapshots out of the box.
I could fiddle around with it and i suppose i could make a snapshot before
running "apt upgrade", but since that never failed for me, i would touch
something very stable for little apparent benefit. Let's say Debian 10 will
support btrfs snapshots on updates, i'll consider using btrfs for the next
installation, but not before.

Did you read the link from the ostree people? Let's pretend Debian 10 offers
to choose between OStree-like updates and btrfs snapshots: I'd probably choose
OStree and stick to ext4/xfs.

~~~
lomnakkus
> Still, dpkg doesn't support snapshots out of the box.

Yes, but it _SHOULD_ , just because ALL REASONABLE FILE SYSTEMS SHOULD SUPPORT
SNAPSHOTS. Therefore dpkg should _assume_ that such support is avaiable, or
_at the very least_ take advantage of it, when available.

Just to reiterate: You (impersonal!), the "ignorant user", shouldn't have to
even have to think about it.

Does this make my point clear?

(I'm only being this obtuse because you're saying "you're absolutely right",
but apparently not seeing my point. I'm assuming it's some form of
miscommunication, but it's difficult to tell.)

EDIT: Hehe, I'm sorry, that sounded much more aggressive than I intended. I
just think that us software developers could and should(!) do _much_ better by
our users than we(!) currently do. My excuse is that most of my stuff is web-
only, so at least I can't do the accidental equivalent of "rm -rf /", but...

~~~
buster
Still, i think that my filesystem shouldn't accumulate that much complexity.
Maybe a layered approach similar to Redhats Stratis is a better way.

------
bedros
I think this is a political move disguised as technical move

oracle pays the developers of btrfs [0]

redhat hates the guts of oracle, since oracle released oracle linux, which is
a clone of redhat enterprise (based on centos)

so, redhat wants to cripple btrfs and hurt oracle.

However, btrfs is my favorite FS, been using it on my home computer and backup
drives for at least 6 years, before it was included in the kernel, love the
subvolumes, snapshots, and compression; never had issues with it .

[0] [https://oss.oracle.com/~mason/](https://oss.oracle.com/~mason/)

[Update] Chris mason no longer at Oracle since 2012

~~~
ge0rg
_I think this is a political move disguised as technical move_

I think there are solid technical reasons to discourage Btrfs use, just to
quote from the official wiki [0]:

 _> The parity RAID code has multiple serious data-loss bugs in it. It should
not be used for anything other than testing purposes._

Now I don't know if this issue has been addressed already, or which kernels
are affected, but the fact that there is a prominent warning on the wiki
speaks for itself.

Personally, I'm a happy btrfs user deploying a mixed-disk-size array without
parity, with the hope to add redundancy some time in the future. Currently,
btrfs is the only FS allowing to mix disks of any size and to run an optimal
configuration on top of them [1].

[0]
[https://btrfs.wiki.kernel.org/index.php/RAID56](https://btrfs.wiki.kernel.org/index.php/RAID56)

[1] [http://carfax.org.uk/btrfs-usage/](http://carfax.org.uk/btrfs-usage/)

~~~
cyphar
The particular bug that sparked that warning was fixed a while ago, but as a
precaution against "btrfs ate my data" stories they've removed the ability to
create btrfs-raid from the CLI tools (you can still use md RAID with btrfs but
you lose most of the benefits of btrfs that way).

~~~
tw04
Which benefits are those? Both synology and qnap have the ability to detect
and correct bitrot doing btrfs on top of mdraid.

~~~
cyphar
Being able to have non-symmetric disk topologies with redundancy. I believe
that md raid does not support that, while btrfs multi-device does (which is
what I think of as one of the really unique features of btrfs -- not even ZFS
can handle the sort of disk topologies that btrfs can).

~~~
tw04
md-raid absolutely supports that and synology has for a long time. They call
it "SHR". You simply do raid over disk partitions to enable disks of disparate
sizes.

The reason ZFS doesn't support it, and absolutely 0 enterprise storage devices
support this is because as the disks fill up, you sacrifice both performance
and redundancy. Synology won't even support it on their high-end devices for
this very reason. They'll only do it on their devices targeted at home use.

------
JoshTriplett
Has anyone here tried bcachefs ([http://bcachefs.org/](http://bcachefs.org/))
for some of the same use cases as btrfs? What do people think of its current
state?

~~~
lathiat
You'd need to read up on it but the TL;DR i got from previous comments was
that previously it was being funded by a company that wasn't 100% aware of the
entire situation around it (they used it in their commercial product,
management didn't fully understand it was being released as open source,
though I also understand they didn't own the rights to the entire code base so
basically that was necessary effectively). The person developing it left that
company and is seeking his own funding for it but that generally the
development was significantly stunted as a result.

It seems a bit here-say-ish though, so please don't assume I'm entirely
correct on all fronts there and I'd encourage you to research it further!

~~~
joecool1029
>I'd encourage you to research it further!

On that note, their Patreon is a better primer than the website is:
[https://www.patreon.com/bcachefs](https://www.patreon.com/bcachefs)

~~~
lathiat
Happy to see his Patreon is looking "healthier". I mean $1500/m isn't really
that much but I'm sure last I looked it was much lower.

In other news.. consider supporting the people that support you! Personally, I
spent over $100/month on Patreon. Most of those are creators rather than open
source people but there are a couple of open source ones such as Ondřej Surý
who works on PHP packaging in Debian/Ubuntu

~~~
vbezhenar
It's $1050, not $1500. I'm interested in two projects on Patreon (bcachefs and
Matrix) and both projects are not getting nearly enough to be self-funded, so
this raises the question if this model even works for Open Source. So far any
advanced technology seems to be funded by some big corporation and it's not
very good. But, I guess, users just don't care about good inner workings, they
care about things they personally enjoy (cartoons, etc), so funding those
inner workings is still an open question.

~~~
tmikaeld
I think it's an issue with the marketing of it as well, I recently got notice
that some of the most important open source projects I use have a patron page
they depend on, yet didn't show it on github, only on their home page under
donate. Same as with Kickstarter, if you want funds, you have to properly and
visibly ask for it!

I donated a lot to git-annex because he did it right, showing everywhere that
you could sponsor the development.

------
cmurf
Unsurprising. Red Hat has not hired upstream Btrfs developers for years, where
SUSE has hired bunches. Meanwhile Red Hat has upstream ext4, XFS and LVM
developers.

If you're going to support a code base for ~10 years, you're going to need
upstream people to support it. And realistically Red Hat's comfortable putting
their eggs all in the device-mapper, LVM, and XFS basket.

But, there's more: [https://github.com/stratis-
storage/stratisd](https://github.com/stratis-storage/stratisd)

 _Btrfs has no licensing issues, but after many years of work it still has
significant technical issues that may never be resolved._ page 4

 _Stratis version 3.0 Rough ZFS feature parity. New DM features needed._ Page
22 [https://stratis-
storage.github.io/StratisSoftwareDesign.pdf](https://stratis-
storage.github.io/StratisSoftwareDesign.pdf)

Both of those are unqualified statements, so fair or unfair my inclination is
to take the project with a grain of salt.

~~~
gcp
As for the significant technical issues, one thing is the core decision to
make it a CoW system, which has fundamental performance issues with many
workloads that are exactly those used in the server space. You can disable
CoW, but you lose many reasons to use btrfs in the first place if you do.

When I gave up on it there were also fundamental issues with metadata vs data
balancing, not-really-working RAID support, and so on...

~~~
pgaddict
I find the suggestion that the technical issues are caused by the CoW design a
bit strange.

Sure, making the filesystem CoW-based means there are some inherent costs, but
it allows the filesystem to implement some interesting features (e.g.
snapshots) in a more efficient way. For example if you want to do snapshots
with ext4/xfs, you'll probably do that using LVM (which you can see as turning
the stack into a CoW). In my experience the performance impact of creating a
snapshot on ext4/LVM is about 50%, so you cut the performance in half. While
on ZFS the impact is mostly negligible, due to the filesystem is designed as
CoW in the first place.

And thanks to ZFS we know that it's possible to implement a CoW filesystem
that provides extremely stable and balanced performance. I've done a number of
database-related tests (which is the workload that I do care about) and it did
~70-80% TPS compared to ext4/xfs (without snapshots). And once you create a
snapshot on ext4/xfs, the performance tanks, while ZFS works just like before,
thanks to the CoW design.

Unfortunately, BTRFS so far hasn't reached this level of maturity and stable
performance (at least not in the workloads that I personally care about). But
that has nothing to do with the filesystem being CoW, except perhaps that CoW
maybe makes the design more complicated.

~~~
gcp
> _it allows the filesystem to implement some interesting features (e.g.
> snapshots) in a more efficient way._

Interesting features are worthless when reading and writing data is
prohibitively slow. Or when there are documented cases where updating a file
in random-access manner can cause its storage requirement to balloon to
blocks^2.

~~~
cryptonector
There's a write magnification effect when using CoW. The ZIL helps with this
because the ZIL itself is not CoW'ed, and it allows deferring writes, which
allows more transactions to share interior metadata blocks, thus reducing the
write magnification multiplier. I don't get where you get O(N^2) from.

As to snapshots, who cares, they cost nothing to create and they do not slow
down writes -- they only slow down things like zfs send (linearly) and they
cost storage over time, but not much more.

~~~
gcp
You are confusing _storage_ requirements with write amplification (which is
another downside). They're totally different.

------
lathiat
This is specific to RHEL7, notably that they won't backport any further kernel
updates and won't move it from Technology Preview to release. Red Hat wasn't
really driving btrfs development at all from what I am aware of.

⁠Btrfs has been deprecated

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.

The Btrfs file system did receive numerous updates from the upstream in Red
Hat Enterprise Linux 7.4 and will remain available in the Red Hat Enterprise
Linux 7 series. However, this is the last planned update to this feature.

Red Hat will continue to invest in future technologies to address the use
cases of our customers, specifically those related to snapshots, compression,
NVRAM, and ease of use. We encourage feedback through your Red Hat
representative on features and requirements you have for file systems and
storage technology.

------
X-Istence
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.

~~~
jabl
Ouch?

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

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

~~~
X-Istence
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.

------
RX14
I've done many bad things to BTRFS, used it on multiple drives of differing
sises, used it on drives connected over the cheapest USB to SATA adapters I
could find, used it on disks with consistent corruption for over a year, and
it's handled it gracefully.

I've also been using btrfs as the backend to docker for a long time on my
desktop PC and never noticed any problems. BTRFS has been rock solid for me. I
don't doubt it is more unstable than other filesystems, however it seems i
haven't been unlucky enough to experience any issues.

When using BTRFS, i've always stuck to the latest kernel releases, and run a
scrub + balance every month. This is the advice I heard from people who used
btrfs, and I wonder how many of the people who complain about data corruption
do these steps. Perhaps their corruption bugs are solved in a newer kernel
version. I've had multiple scrubs pick up data corruption, which other
filesystems wouldn't have found.

The only time btrfs corrupted my data was when I used the ext4 to btrfs
conversion tool, it created an unmountable FS and then I just migrated my data
manually.

~~~
rleigh
You shouldn't _have_ to do these steps.

Manual balancing is a workaround for a critical flaw in the implementation.

In my last major use of Btrfs, whole archive rebuilds of Debian, it would take
less than 48 hours to completely unbalance a brand new Btrfs filesystem. ~25k
snapshots continuously created and deleted over the period in 20 parallel jobs
absolutely toasted the filesystem, even though it was 1% utilised for the most
part, 10% at peak usage.

The point I want to make is that a Btrfs filesystem can become unbalanced at
some indeterminate point in the future, which makes it impossible to rely on
if you want to guarantee continued service.

I've also suffered from a number of dataloss incidents which likely are fixed
now, but despite lots of bugfixing, there are still major flaws to address.

------
jorrizza
Strange decision, as systemd-nspawn[1] specifically mentions and supports
btrfs as a CoW filesystem for its containers. And as far as I understand,
systemd is primarily developed by Red Hat employees. So either they'll add
support for CoW alternatives, or they'll remove btrfs support from systemd-
nspawn all together.

[1]: [https://www.freedesktop.org/software/systemd/man/systemd-
nsp...](https://www.freedesktop.org/software/systemd/man/systemd-nspawn.html)

~~~
amorphid
There's nothing which prevents you from creating an empty block device file,
putting btrfs on that, and mounting it.

------
josteink
Deprecated? In favour of what?

Will Redhat too (like Ubuntu) start shipping ZFS?

~~~
tbrock
XFS is the default FS on RHEL now, so likely that.

~~~
vacri
Do you know if XFS can shrink volumes yet? As far as I'm aware, that's the
only limitation it has compared to other filesystems of that era.

~~~
rwmj
It can't, but you're probably better off using trim/discard/virt-sparsify
rather than shrinking filesystems. Even on filesystems like ext4 that support
it, shrinking can cause strange fs performance problems.

------
sparky_
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](https://en.wikipedia.org/wiki/Btrfs#Subvolumes_and_snapshots)

~~~
rleigh
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.

~~~
tylerjd
Are you trying to say that BTRFS is supposed to compete feature-to-feature
with ZFS? It's not.
[https://lwn.net/Articles/342892/](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.

~~~
cryptonector
Yes, that's what rleigh is saying. It's what I'm saying.

ZFS sets a very very high bar indeed. There are things that could be done
better (I've talked about some of those on HN). But pound for pound, it's the
best storage stack today and has been for over a decade. ZFS is the benchmark
against which all others are to be stacked. There will be applications for
which you will find a more performant solution, maybe, but altogether, ZFS has
been the last word in filesystems for a long time now.

The most interesting competition, IMO, is from HAMMER. We'll see how that
progresses.

------
kureikain
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.

~~~
beedogs
Unfortunately, RedHat tends to be the trendsetter in the Linux world. Once
it's gone from RHEL, it'll be gone from most other RPM based distros soon
enough. It's kind of a shame that one company has grown to dominate the Linux
software ecosystem, often to the detriment of all involved.

~~~
smarnach
RPM-based distros make up maybe 10 % of the Linux installations these days, so
we should not overstate RedHat's influence.

~~~
rantanplan
RHEL makes up maybe 99.9% of the Linux _enterprise_ installations these days,
so we can't overstate RedHat's influence.

~~~
cyphar
I don't think that number is even close to accurate. SLE almost certainly
makes up more than 15% of the market alone. And that's ignoring all of the
other enterprise distributions.

I believe that 2015 estimates from the IDC[1] had RHEL at ~60%, SLE at ~20%,
Oracle Linux at ~12% and "Other" at ~8%. But I can't access the document at
the moment.

[1]:
[http://www.idc.com/getdoc.jsp?containerId=US41360517](http://www.idc.com/getdoc.jsp?containerId=US41360517)

------
parasubvert
Concourse (which is a CI/CD system that orchestrates Docker containers)
recently switched from btrfs to overlay to fix performance and stability
issues.

For those with morbid curiosity on the many stability issues with btrfs as a
container file system, this is chronicled in Github:
[https://github.com/concourse/concourse/issues/1045](https://github.com/concourse/concourse/issues/1045)

------
alexdowad
I tried btrfs and got bitten by bugs; not doing that again. Judging from this
move by RH, it looks like I wasn't the only one.

~~~
lucb1e
What bugs?

I recently setup a software mirroring raid with btrfs and I'm loving features
like checksumming. It makes me feel my data is quite safe and can't bit rot
anymore. So far it is working fine.

~~~
rodgerd
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?

~~~
jdmulloy
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 without any virtualization
overhead.

~~~
rodgerd
> 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.

------
headlands
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.

~~~
fundabulousrIII
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.

------
ericfrederich
I ran Fedora some years ago when btrfs support was added. I thought the idea
to be able to roll back after a yum update messes things up was cool... in
practice, it's a lot more complicated than hitting some "rollback" button in
the system update gui.

------
erikb
Why is there no explanation for this? It seems weird to deprecate something
that most people haven't even started using yet.

------
snvzz
On a non-totally unrelated note, Matt Dillon recently updated the HAMMER2
design document.

[https://www.dragonflybsd.org/hammer/](https://www.dragonflybsd.org/hammer/)

~~~
kzrdude
Any notable changes, or what do you take note of?

------
shmerl
That's weird. What do they have against btrfs?

~~~
nul_byte
They don't see it as stable enough to move beyond tech preview.

~~~
rurban
It is also extremely slow. And the known RAID problems didn't get better.

------
pmlnr
Great... So can I please have something that can do transparent compression?
That is my sole reason for using btrfs. (My personal stack is on ZFS with
Debian and I'm never going to look back from that, even if I sometimes have
speed issues due to SATA instead of SAS system underneath it; ZFS compression
and snapshots are incredibly powerful.)

------
sargun
This is disheartening to hear. We recently (<3 months ago), introduced Btrfs
into part of our fleet. This probably made us one of the larger Btrfs users.
If Btrfs falls out of general favour, I'm afraid it may impede our ability to
keep using it.

Given our use-case, multi-tenant containers, there weren't many choices which
had sane snapshotting support, as well as quotas and some level of subtrees.
ZFS on Linux has its own share of issues. I won't say that Btrfs was without
issues -- there is still a lot of performance work that needs to be done,
especially in a multi-tenant workload, but it looked like there were solutions
available.

XFS is an excellent filesystem, and it may work well for our usecase in the
near future. It's exciting to see new XFS features landing, like reflinks, and
collapsing ranges. Hopefully, folks like Redhat continue trying to bring XFS
to the future.

------
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...](https://gitweb.dragonflybsd.org/dragonfly.git/blob_plain/HEAD:/sys/vfs/hammer2/DESIGN)

------
0xFFC
Wow, I thought their long term plan was to switch to Btrfs. Now it is
deprecated? What happened there?

~~~
lathiat
I think you might be confusing with SuSE?

Generally though sadly btrfs just isn't getting the man hours from any
commercial sponsor it seems :(

~~~
cyphar
Facebook, Fujitsu and SUSE are all actively contributing to btrfs. The idea it
isn't getting "the man hours from any commercial sponsor" is ludicrous.

~~~
jeltz
And this is what makes me worried about the design of btrfs. If after all
these man hours Redhat thinks it still is not stable enough I worry if it ever
will be.

~~~
cyphar
Why are you shifting the goal posts? Also, Red Hat has not been a significant
contributor to btrfs for a while (they've mostly been working on XFS and
lvm/devicemapper) so them dropping it is hardly a surprise -- Red Hat is not
the arbiter of what is a good technology, and there are many other parties
that work on Linux.

~~~
jeltz
Are you confusing me with someone else? Because I have never claimed that
Redhat has been a major contributor behind Btrfs nor have I claimed that Btrfs
development is lacking in contributors.

And to me this is just another voice which is septical of the current state of
Btrfs. And while Redhat is not the only voice, it is an important voice.

~~~
cyphar
Sorry, I was responding to a comment that said that btrfs didn't have any "man
hours" behind it and your response was basically "and even with those man
hours Red Hat still decided against it". It didn't feel like a reasonable
response in that context.

Red Hat is an important voice, but please remember that supporting something
as part of an enterprise distribution requires that you have engineers that
work upstream constantly on said project. You can't just passively support
something.

A while ago, most of Red Hat's btrfs developers moved to Facebook and clearly
they decided that it wasn't worth the money to hire more people to support
btrfs on RHEL. If they didn't see customer demand for it, why should they
burden their kernel team with supporting something that nobody is asking them
for? SUSE supports btrfs (and not just as a technical preview) and they can
switch to SLE if they really want btrfs.

Just because something isn't shipping in RHEL doesn't mean that Red Hat
decided that btrfs was bad. They likely decided that either their customers
are better suited with other options, or they don't think the cost of getting
more engineering talent would be worth it. Btrfs is still shipping in Fedora.

[I work for SUSE.]

------
mhd
Is JFS still a thing in the Linux world? I remember using it for some
partitions not because it was particularly high performant, but because it was
supposed to have very few worst case scenarios…

------
jmspring
It's OT but how many people actually use RHEL? Or CentOS (more likely).

I'm not a fan of systemd, but have really loathed CentOS/RHEL compared to
Debian/* for years.

~~~
myrandomcomment
As a general rule if the end customer was finance/bank their Linux flavor was
RedHat (someone to yell at when it broke). Other tech companies / web types it
was Ubuntu. This was my experience in over 4 startups where these were are end
customers. Your mileage may vary.

~~~
jsmthrowaway
CentOS is _extremely_ popular among startups. It lets you directly use RPMs,
which many software publishers distribute on their own (not the case for debs,
often), and gives you an upgrade path to buy RHEL when you want someone to
yell at and not throw away all your automation.

I’m not trying to start a flame war here (honest), but among most “usual web”
ops folks I know, the opposite of what you’re suggesting seems to hold and
Debian/Ubuntu are looked at as an odd choice. It’s probably hire #1 going with
what they know, more than anything, and it could very well be selection bias
regarding the people I know. I’d love to see stats.

I’ve been working with CentOS or OEL in my own roles for several years now,
and I’ve never chosen it. (Not saying I wouldn’t, just that it’s been there
when I get there.)

~~~
vacri
There are just as many publishers that supply debs and not rpms. It really
depends on what you're after.

But if you look at the usage, north america is generally more redhat-family
and europe is generally more debian-family, even in the SuSE patch that is
Germany...

------
louwrentius
Sounds to me that Btrfs is done for long-term. So now what?

~~~
cyphar
Facebook, Fujitsu and SUSE all contribute to btrfs and it is still being
actively developed (it's the default filesystem for SUSE Linux Enterprise).
Red Hat stopped contributing a while ago since most of their btrfs developers
moved to Facebook.

"Done for the long-term" is a major overstatement IMO.

~~~
tjoff
Well, for those of us that have been waiting on btrfs for a frigging decade I
get the feeling that it is never going to be ready.

If I wait another decade, will btrfs have matured? Will there be _ANY_ half-
modern filesystem for linux? I'm not convinced.

Currently bcachefs seems more appealing but well, long way to go there as
well.

~~~
osandov
What problems have you had with Btrfs recently?

~~~
tjoff
That, exact, question is the question you get, and has got for years and
years, when questioning btrfs maturity. It seems as if btrfs always "just
yesterday" got mature just when that last thing was fixed.

Sorry, but I don't believe enough in btrfs to try it out for real (and don't
have time to play with it just for fun). Especially when playing with more
advanced features, the status page does not inspire confidence.

The paragraph on btrfs in
[https://www.patreon.com/bcachefs](https://www.patreon.com/bcachefs) seems
spot on and exactly the feeling you get after spending a decade of hope on
btrfs. And that kind of review is exactly what you don't want on the brand new
finally-we-can-store-data-properly-on-linux solution.

~~~
rrdharan
I found the patron site annoyingly hard to read on this device, so here's that
paragraph, in case anyone is wondering:

btrfs, which was supposed to be Linux's next generation COW filesystem -
Linux's answer to zfs. Unfortunately, too much code was written too quickly
without focusing on getting the core design correct first, and now it has too
many design mistakes baked into the on disk format and an enormous, messy
codebase - bigger that xfs. It's taken far too long to stabilize as well -
poisoning the well for future filesystems because too many people were burned
on btrfs, repeatedly (e.g. Fedora's tried to switch to btrfs multiple times
and had to switch at the last minute, and server vendors who years ago hoped
to one day roll out btrfs are now quietly migrating to xfs instead).

------
seesomesense
Not surprised. I have been using BTRFS for years. Unfortunately, one gets the
feeling that not too much development has been going into it.

~~~
horusthecat
Having been using BTRFS at home for years, i get the exact opposite
impression... I've had bugs (kernel panics) that just disappear on the next
update. I'm happy with the RAID1 ease of use. But even there, like some have
said, manual scrub/balance--which is still nice to have--indicates a design
flaw.

If I was in ops I would not use btrfs on anything but lab experiments... if i
can get hardware RAID, then I can blame the vendor and the equipment

------
vbezhenar
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.

~~~
tylerjd
> deprecated and unsupported LXC

Where did you hear this? This is news to me.
[https://linuxcontainers.org/](https://linuxcontainers.org/) and
[https://github.com/lxc/lxc](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.

~~~
vbezhenar
LXC is unsupported by RHEL. They chosen Docker as a primary container
solution. LXC as project is fine, of course.

------
drawnwren
I know this says redhat.com, but title is still a bit misleading. Btrfs has
been deprecated on RHEL, but it is still under active development on its own.

~~~
em3rgent0rdr
HN has a problem of users posting misleading titles.

------
pmontra
Offtopic, but if anybody from RedHat and especially Mozilla read this, go to
that page with an Android phone, possibly with a small screen:

To RedHat: do something for that menu at the left. It stays in the way when
scrolling and zooming. The X to close it is not immediately visible on a small
screen. Expected behavior: the menu scrolls away with the page and doesn't
stay fixed in the way of the reader.

To Mozilla: open the page with Opera and copy what you see there. Tldr:
autofit the text in the screen width. Maybe Chrome does the same. Btw, reader
mode doesn't kick in.

~~~
tyfon
Worse, I browse without javascript and their page has no text.

It's utterly terribly designed to be an open source information page.

~~~
creshal
Even as paying customer I wouldn't want to put up with that shit.

~~~
lunchables
You mean ESPECIALLY as a paying customer! You paid for the right to bitch, and
you should.

------
snakeanus
Still waiting for bcachefs. It's like btrfs except it does not suck. It also
has proper encryption.

~~~
betaby
How many developers involved in bcachefs full time? What I've heard it's a one
man show.

------
kodfodrasz
I wonder if this is a response to Oracle's Java9/Jigsaw push, where RedHat was
forced to give up its position.

