
A straight talk about btrfs - cyphar
https://www.suse.com/communities/blog/butter-bei-die-fische/
======
jacknews
A data-point of one, and I only have a few TB spread over a handful of disks,
but I lost an entire 1TB btrfs volume recently because of a single disk sector
gone bad (of course, I have backups, but it's a pain to restore 1TB, not to
mention racking of the nerves (will the backup drive fail with sudden heavy
use?)

It's the only FS I've ever been unable to recover data from, at all, (I've had
quite a few disks with errors before going back 25 years), and so it's no
longer on my list of filesystems-I-trust.

~~~
vog
Serious question: Why would anyone today use BTRFS, given that the battle-
proof ZFS has finnally been ported to Linux for quite some time?

~~~
josteink
> Why would anyone today use BTRFS, given that the battle-proof ZFS has
> finnally been ported to Linux for quite some time?

It's only been available out of the box in a simple-to-use and supported
fashion in 1 Distro for barely 1 year.

You can hardly say it's been widely available, nor for a "quite some time".

~~~
zacmps
ZFS on Linux has official support for Arch, Debian, Fedora, Gentu, OpenSUSE,
RHEL &CentOS and Ubuntu.

~~~
cyphar
It has "official support" from the ZoL folks. And yes, openSUSE has ZFS
packages in OBS. But we sure as hell don't ship them by default, or in our
official repos. The same applies for Arch, Debian, Fedora, Gentoo, RHEL and
CentOS.

Ubuntu is the only distribution that official supports ZoL, and actually ships
it in it's official repositories (and by default). What that means is that
Canonical is effectively saying "we trust there's no legal reason why we
cannot do this." No other distribution has made that claim.

EDIT: Actually NixOS also supports it, but the point stands.

~~~
Filligree
Well, also NixOS.

------
danieldk
_If Brazil, one of the world biggest producers of beef, would announce to stop
producing fish: would you wonder, whether Peru, one of the world biggest
producers of fish, would stop producing fish?_

I find this quite weak argumentation coming from SUSE. Novell/SUSE was also
(by far) the largest contributor to AppArmor at some point. And SUSE used it
as the MAC framework in their consumer and enterprise distributions. Then
seemingly out of nothing they fired the AppArmor team.

~~~
jabl
Oh? What are they using now then? SELinux?

~~~
sp332
_AppArmor is configured to run by default on any fresh installation of SUSE
Linux Enterprise Server._
[https://www.suse.com/documentation/sles11/book_security/data...](https://www.suse.com/documentation/sles11/book_security/data/sec_aaintro_enable.html)

All the drama was back in 2007.
[https://web.archive.org/web/20160410165126/http://www.cnet.c...](https://web.archive.org/web/20160410165126/http://www.cnet.com/news/novell-
lays-off-apparmor-programmers/) Looks like it blew over by 2008
[https://news.opensuse.org/2008/08/20/opensuse-to-add-
selinux...](https://news.opensuse.org/2008/08/20/opensuse-to-add-selinux-
basic-enablement-in-111/)

------
btilly
For those who wonder who deprecated it, Red Hat did in the release notes for
7.4.

Search for brtfs in [https://access.redhat.com/documentation/en-
US/Red_Hat_Enterp...](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) for
details.

~~~
lemoncucumber
As has been discussed in other threads, RHEL's kernels are ancient compared to
mainline and so they probably decided it's just too much work to continually
backport btrfs changes onto increasingly dated kernels. The sky is not
(necessarily) falling.

~~~
danieldk
But if they thought that btrfs was the future, they would definitely have put
in the manpower to maintain and backport btrfs. Red Hat probably believes that
XFS + LVM et al. can provide the necessary functionality for enterprise setups
on a more reliable basis.

~~~
catdog
They were never heavily invested in btrfs and they simply already employ a lot
of XFS developers. I also don't think it's that easy to put more manpower into
it. People with expertise in such such a rather complex niche field don't grow
on trees.

~~~
72deluxe
But do they grow on btrees?

Filesystem joke, hilarious I know

------
willtim
I'm really confused by the choice of development process for BTRFS. First they
write huge amounts of experimental/buggy code and then spend years trying to
fix it. Reliability was obviously not the primary goal and I doubt they will
be able to retrofit it.

------
memracom
This is a bad move. More than ever we need Linux standards and this goes in
the opposite direction. It would be OK for SUSE to support btrfs as a first
class choice of filesystem but the extfs family should be the standard one.

And ZFS works just fine on Linux. If people want to use it, then the distros
should not put roadblocks in their way and that means, ZFS should also be
supported as a first class choice for servers.

Note that "support" is different from licensing and from "included in our
install repo". It is OK to have different licensing for things like this and
to install it from a non-distro repo. Look at PostgreSQL for an example of how
you can install a mission critical tool from a distro-compatible repo that is
run by the upstream project, in this case, PostgreSQL.

But even though it comes from a different repo, it should be "supported" by
the distro to the extent that they make a best effort to help people resolve
problems. It doesn't mean that you need to be experts in every nuance of the
tool and the best way to do that is to maintain a good working relationship
with these upstream projects.

Something like ZFS or PostgreSQL are mission critical tools that use Linux as
the interface to the hardware, My comments do not apply to any random app or
utility that someone wrote for Linux. Perhaps btrfs belongs in this class but
I personally don't know since I have not used it.

~~~
gens
Linux has lately gotten a lot of bad standards.

~~~
iso-8859-1
Such as?

~~~
gens
Most of the things by freedesktop.org in the last.. idk 5-10 years. Console-
kit/logind, AppData, dbus being used for the lower parts of user-space, and
probably many more that i don't recall now. Oh, and pulseaudio.

EDIT: How could i forget polkit.

------
giis
Recent Redhat decision may also be related to their investment in Storage
products Ceph (~175 million in 2014) and GlusterFS (~125million in 2011) not
just about stability of btrfs.

As someone who previously experienced with distributed storage like emc-Isilon
and also fuse-based glusterfs, btrfs has huge potential for enterprise
storage. It does also need more effort on testing front at this moment. hoping
that soon btrfs will become default fs for most Linux distros.

~~~
jle17
I read somewhere (probably on HN) that it could be related to their
acquisition of Permabit, a company which seems to be producing Linux software
for deduplication, compression and thin-provisionning. This seems more in-line
with what btrfs has to offer.

------
Elrac
When a CEO/CTO uses the words "straight talk" I prepare for a copious load of
meaningless waffling. Was not disappointed!

~~~
appleflaxen
huh. i found it to be coherent and not-particularly-heavy on techno-
doublespeak.

while it wasn't particularly edgy/straight, it certainly wasn't "meaningless
waffling".

i got the impression the title came from wanting to use the german idiomatic
expression for "straight talk" in order to work in the butter-cow pun.

------
hyperfekt
I've taken a long look at COW filesystems in these past days as part of me
wanting to set up a new workstation, and it appears that while btrfs is not a
viable long-term solution for its quality issues and lack of development, ZFS
does not have the pretense of being a filesystem for the general usecase, as
exemplified by the lack of offline deduplication, defragmentation, the
possibility to easily change disk configurations, and much more. Maybe we
should consider accelerating the development of bcachefs as the future of
reliable and feature-rich filesystems on Linux, which appears both more modern
and holistic, but still has quite some ways to go. A new filesystem is
necessary because many things we should demand from them are not modularly
composable without massive disadvantages. Implementing compression as a layer,
for example, demands basically creating another filesystem to manage the
space, with great overhead in all dimensions. Similar things go for the
consistency guarantees provided by COW or the deduplication and snapshotting
that depends on it.

------
kingwill101
2 days ago I shutdown my laptop and all was working out great at that point.
Now yesterday I turned back on to get some work done and couldn't pass
maintenance mode because my home partition got corrupted somehow. Took me all
day literally to get it working. I have since changed that partition back to
ext4 leaving only / as btrfs

------
unixhero
I use BTRFS for non critical data, like scratch data and second backup
archives. This is because I can stretch it out over many old harddrives I have
laying around. The memory footprint is also very low. And it comes with
compression!

But for everything else, I have rammed up, manned up, and use ZFS.

------
j_koreth
Is there any reason why Oracle contributes so much to Btrfs while maintaining
ZFS? Or am I mistaken in Oracle's relationships with ZFS

~~~
Elv13
Oracle sells Oracle Linux, a RedHat clone. ZFS on Linux (ZoL) isn't controlled
by Oracle, it is a fork of OpenSolaris version of ZFS. The ZFS sold by Oracle
on Solaris isn't the same product and doesn't support Linux. Oracle doesn't
want to support it on Linux because it would fragment one of the remaining
cash cow they got from Sun. And anyway, they probably can't support ZoL even
if they wanted to without putting themselves into self induced legal gray
water. Apparently, they intend to move Solaris into a rolling model like
Windows 10, but focused on legacy. They can sell ZFS there without affecting
their Linux operations. There is also a rumor of a deal with NetApp not to
support ZFS on Linux. All combined, BTRFS is a better suited tech for them to
support.

~~~
rehemiau
I was wondering, how does Illumos fit into all this? Is their ZFS the Oracle-
controlled one?

~~~
cyphar
illumos is the repo of record for OpenZFS[1], which is the community fork of
OpenSolaris' ZFS (which is now proprietary). Most of the really cool new
features are in OpenZFS because it has far more developer involvement (from
FreeBSD, illumos, etc).

[1]: [http://open-zfs.org/wiki/Main_Page](http://open-zfs.org/wiki/Main_Page)

------
rodgerd
That's gotta be the weasel-wordiest straight talk I've seen in a wee while.

Here's a fact: the upstream's official statement is that RAID 1 isn't
production-ready.

~~~
wtallis
> " _Here 's a fact: the upstream's official statement is that RAID 1 isn't
> production-ready._"

That doesn't seem to match anything I've seen. The btrfs status page
classifies RAID1 and RAID10 features as "mostly OK". The one and only
documented caveat is that when a disk in a RAID1 fails, you should mount the
filesystem as read-only until you are ready to fix the problem by either
replacing the failed disk or converting to a non-RAID profile. There's a real
bug underlying this limitation, but the only way to encounter this bug is to
be quite cavalier about how you handle a degraded array, by doing something
that you shouldn't _expect_ to be safe.

~~~
michaelmrose
Mostly OK != production ready.

A degraded array should have no substantially greater risk of failure than the
single disks the vast majority of people rely on daily. I can think of one
obvious reason one might mount the degraded array simply to copy data from it
to a different arrangement. Another reason is in a non enterprise use case a
desktop users might not instantly have a disk available and might mistakenly
believe that this is no more risky than having only one disk in the first
place.

This is ridiculously flaky for something that is supposed to be years in
development with backing from major companies.

This confirms my feeling that btrfs belongs in the waste basket.

~~~
wtallis
> Mostly OK != production ready.

Don't nitpick about what a two-word summary implies when there's only one
underlying bug at issue. Just address the bug itself. "Production ready" never
means 100% bug-free.

> A degraded array should have no substantially greater risk of failure than
> the single disks the vast majority of people rely on daily.

If you are comfortable dropping from the RAID1 profile to a non-RAID profile,
btrfs requires you to explicitly make this conversion; there's no safe way to
make it automatic. Forcing the filesystem to accept writes while it's still in
RAID1 mode but is incapable of providing RAID1 data integrity is something
that you should expect to cause problems.

> I can think of one obvious reason one might mount the degraded array simply
> to copy data from it to a different arrangement.

You can mount read-only as many times as you want if you're going to copy the
remaining data to a different filesystem. If you want to do an in-place
recovery, the current limitation is only that you shouldn't mount the degraded
array as writable until you're ready to make it not degraded anymore.

------
gbrown_
TL;DR - Don't be dissuaded by marketing, here's some more marketing.

