Btrfs Usage/Complaints

Hi all -

Over the past year, btrfs has received substantial attention in the
areas of both stability and performance. I’ve been running it,
personally, on a 4 TB data volume as well as my root partitions for my
openSUSE 12.2/12.3 systems. I’ve been able to do stress tests like a
long fsmark run simultaneously with creating and removing snapshots
(with syncs to force them to disk) and haven’t run into any issues.
David Sterba, who’s been leading the charge at SUSE for btrfs stability
has likewise regularly run it through an array of torture tests and has
found that problems are occurring a whole lot less frequently than they
have in the past. The upstream btrfs community in which we participate
has also started focusing less on feature development and more on
stability and performance.

But these are only anecdotal data points from two file system guys and
if my experiences working for a major operating systems vendor have
taught me anything, it’s that our users can be a lot more creative at
finding ways to break things than we are.

So, I’d like to hear your stories. What’s worked for you? What hasn’t
worked? What would you consider the pain points with using btrfs?

Lastly, I’d like to ask that you take the opportunity to test with the
latest openSUSE Factory kernel running 3.10-final. 12.3 used the 3.7
kernel since it was the most recent release going into the beta cycle
and we’ve seen a bunch of btrfs fixes since that release.

I look forward to your feedback and the opportunity to improve btrfs for
the 13.1 release and future releases.

Thanks!

-Jeff


Jeff Mahoney

While I know many still consider btrfs to be beta and would not use it in
production (and I MAY agree with that, depending on the situation, though
honestly I would probably try it as long as I had regular reliable backups
just in case), I personally use btrfs and like it. I run it on my primary
laptop (this one) on which my entire life resides, using openSUSE 12.2
x86_64. Before this I rant it on my work (and only) laptop on which my
entire life, then, resided (openSUSE 12.1 x86_64). In both cases I have
had no known issues of data loss. In both cases I have had exactly one
kernel panic that may have been related to the filesystem, and it was
because I was being stupid (pushing I/O in four KVM VMs running within my
host btrfs filesystem doing a ton of I/O) and, even in that case, nothing
seemed to be damaged after restarting the box.

The only real issue I think I had was with my 12.1 laptop which had
spinning drives. Both then as well as now full disk encryption (except
for /boot) was in use, and when I built that system I partitioned
everything into one area without any subvolumes. As a result, my
snapshots that happened thanks to Yast/zypper included the /home directory
and likely caused a lot more work than necessary. By the end, before I
purchased my current laptop (SSD), I was experiencing some issues that I
felt were related to I/O, but I did not know how to prove that the problem
was because of btrfs, snapshots within btrfs, encryption, LVM (for
encryption), or just a crappy spinning drive. Beacuse of the SSD, the
newer version of openSUSE, or correctly using the default partitioning
setup more during this newer system’s setup, I have not experienced the
same issue at all with 12.2, though I’ve been running for about nine
months now, using it all day, every day.

All in all, I trust it. I also do backups that I feel are pretty
reliable, but still trust btrfs for everything. I would not necessary
recommend it for a high-I/O filesystem (hosting VMs) but I still do it
because I’m a glutton for punishment. :slight_smile:

Good luck.

On 2013-07-04 17:29, Jeff Mahoneyu wrote:

> So, I’d like to hear your stories. What’s worked for you? What hasn’t
> worked? What would you consider the pain points with using btrfs?

The thing that keeps me from using btrfs for real is this:


man btrfsck
....
VAILABILITY
btrfsck is part of btrfs-progs. Btrfs is currently under
heavy  development,  and not suitable for any uses other
than benchmarking and review.  Please refer to the btrfs
wiki http://btrfs.wiki.kernel.org for further details.

Ie, there is no repair possible if the system breaks. In fact, there
have been, perhaps 3 or 4, people coming here for help with a broken
filesystem and the only advice we could give was to reformat the
filesystem. Some reformatted as btrfs, some went back to ext4.

In fact, there is a sticky on the install.login forum that warns new
users not to use btrfs:

View this thread here: Thread: Advisory June 2013: New Users beware of
using the BTRFS filesystem

There is one feature of btrfs that I’m very interested in: compression.
There was one person testing it here and asking if we knew about it,
because it did not work. I have tried to locate the post but failed.
…] oh, yes, found it:

View this
thread here: chattr: Invalid argument while setting flags on
(compression on btrfs)

or via nntp:
Subject: chattr: Invalid argument while setting flags on (compression on
btrfs)
Newsgroups: opensuse.org.help.install-boot-login
Date: May 2013

There is not much info, though. He did open a Bugzilla on the issue, but
got absolutely no response :frowning:

Bug 818373 -
chattr cannot add compression flags (+c) to some files on btrfs

Me, I would be interested in using a compressed filesystem for long term
email storage, for instance. But it has to be absolutely reliable; if it
breaks, it has to be repairable - even if I do daily backups, I can not
afford to lose a critical email.

Another area of interest for me would be handling of small files: is it
comparable to reiserfs? For example, I have a reiserfs partition
dedicated to news storage. It currently holds 279358 files in a thousand
directories (just 556,091,236 bytes). This one I can afford to break, in
case of reformat I just download them again.


Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

I’m trying btrfs in a GNOME Live factory install, and the activities view is crashing the system. No response to the keyboard or power button, only a forced shutdown. This wasn’t happening with ext4. Any way to confirm this is or isn’t a btrfs issue?

My original performance thread is the following in case it gives better
info, and a description of a similar (or same) symptom came up in the
…install-boot-login group today.

https://forums.opensuse.org/showthread.php?threadid=473941

New thread from somebody else on 12.3;

http://forums.opensuse.org/showthread.php?t=488932

Good luck.

One problem I’ve had with installing 13.1 RC1 on a laptop was that I
could not get wireless connection to work at all. I tried both the
default NetworkManager and ifup. I checked settings with what I had
for 12.3 and they matched - apart from the device name having changed
from wlan0. I then tried connecting via Ethernet and could not get
that to work either. I’d had some difficulty with B1 but eventually got
wireless to work after changing a setting that shouldn’t have made a
difference.

I then stopped for a think. I’d also got Ethernet connection to work
‘out of the box’ so to speak on a different machine. The only
difference I could think of was that I had installed ‘/’ on its own
btrfs partition for 13.1 on the laptop whereas, for 12.3 on that
machine and 13.1 on the other, it was on ext4. I couldn’t think why
this would make a difference but re-installed 13.1 with the ‘/’
partition formatted as ext4. This time, wireless connectivity was
achieved without a hitch.


Graham P Davis, Bracknell, Berks.
openSUSE 12.3 (64-bit); KDE 4.11.2; AMD Phenom II X2 550 Processor;
Kernel: 3.11.4; Video: nVidia GeForce 210 (using nouveau driver);
Sound: ATI SBx00 Azalia (Intel HDA); Wireless: BCM4306

I installed 13.1RC1 three times on one machine.

First install was to an encrypted LVM, with the root file system use “btrfs”.
Ethernet worked out of the box.

Second install was to a regular partition, with the root file system using “ext4”.
Ethernet worked out of the box.

Third install was to an external USB drive. I installed with KDE live media, and pretty much took all of the defaults.
Ethernet did not work. Switching to NetworkManager got it working.

I had previously installed Beta1 to that same external drive. And ethernet did not work there, either. For Beta1, I made numerous attempts to get ethernet working, both with Yast network settings, and with “systemctl restart network.service”. It never worked. Switching to NetworkManager got it going.

My main point here, is that “btrfs” might not be the cause of your problem.

I tried “btrfs” with 13.1Beta1. I used “btrfs” on the root partition, which was 20G.

After updates, several days later, the root partition hovered at 91% full, probably because of all of those snapshots.

System startup seemed slow. System shutdown seemed slow.


I installed 13.1RC1 into an encrypted LVM on the same computer (different partition, so Beta1 was still there). The root filesystem is 40G, so space probably won’t be as tight.

The generated grub boot menu did not have an entry to boot the 13.1Beta1 on the same system. This is reported as Bug 845589. Similarly, running grub2-mkconfig on the 13.1Beta1 system did not add a grub entry for RC1 (and I did do the crypto and LVM magic to make it visible). The discussion on that bug seems to suggest that this is a problem with the way that the subvolumes are being setup in “btrfs”. I’d say that needs to be fixed.

For my RC1 install, system startup seemed slow and system shutdown seemed slow.


Since then, I have replace the 13.1Beta1 install, by installing 13.1RC1 on those partitions. I switched to using “ext4” for the root partition. Now “grub2-mkconfig” on the “btrfs” LVM install is adding an entry for the 13.1R1 on the “ext4” partition install. And system startup and shutdown with “ext4” seems more normal. Oh, and the root partition is around 35% full. The same software (KDE, Gnome, LXDE, XFCE) was installed.

I will probably revert to using “ext4” when I install 13.1Final on that LVM.

On Thu 17 Oct 2013 01:06:02 PM CDT, nrickert wrote:

Jeff Mahoneyu;2569422 Wrote:
> So, I’d like to hear your stories. What’s worked for you? What hasn’t
> worked? What would you consider the pain points with using btrfs?

I tried “btrfs” with 13.1Beta1. I used “btrfs” on the root partition,
which was 20G.

After updates, several days later, the root partition hovered at 91%
full, probably because of all of those snapshots.

System startup seemed slow. System shutdown seemed slow.


I installed 13.1RC1 into an encrypted LVM on the same computer
(different partition, so Beta1 was still there). The root filesystem is
40G, so space probably won’t be as tight.

The generated grub boot menu did not have an entry to boot the 13.1Beta1
on the same system. This is reported as Bug 845589. Similarly, running
grub2-mkconfig on the 13.1Beta1 system did not add a grub entry for RC1
(and I did do the crypto and LVM magic to make it visible). The
discussion on that bug seems to suggest that this is a problem with the
way that the subvolumes are being setup in “btrfs”. I’d say that needs
to be fixed.

For my RC1 install, system startup seemed slow and system shutdown
seemed slow.


Since then, I have replace the 13.1Beta1 install, by installing 13.1RC1
on those partitions. I switched to using “ext4” for the root partition.
Now “grub2-mkconfig” on the “btrfs” LVM install is adding an entry for
the 13.1R1 on the “ext4” partition install. And system startup and
shutdown with “ext4” seems more normal. Oh, and the root partition is
around 35% full. The same software (KDE, Gnome, LXDE, XFCE) was
installed.

I will probably revert to using “ext4” when I install 13.1Final on that
LVM.

Hi
Yes, you need to reconfigure /etc/snapper/configs/root and also ensure
you configure the time for the daily cron job to run, until this is set
the snapshots don’t seem to get removed properly.


Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE 12.3 (x86_64) GNOME 3.8.4 Kernel 3.7.10-1.16-desktop
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

I’m surprised 20GB went so quickly even with Btrfs on root partition. I’ve only recently turned 22GB using it on Tumbleweed with /home excluded by subvolume, after around 2000 package updates and over 500 snapshots over several weeks (with 12.3’s defaults for Snapper).

How do you set the time for the cron job? I haven’t so far, and it runs daily most of the time since Snapper’s script is in /etc/cron.daily, but not always at the same time of day. However that depends on system up times and when that cron job was last run wrt date and time. At least that’s what I read re cron jobs generally, and the script doesn’t appear to control the time it’s run.

On Thu 17 Oct 2013 03:46:02 PM CDT, consused wrote:

malcolmlewis;2591783 Wrote:
> Hi
> Yes, you need to reconfigure /etc/snapper/configs/root and also ensure
> you configure the time for the daily cron job to run, until this is
> set the snapshots don’t seem to get removed properly.
I’m surprised 20GB went so quickly even with Btrfs on root partition.
I’ve only recently turned 22GB using it on Tumbleweed with /home
excluded by subvolume, after around 2000 package updates and over 500
snapshots over several weeks (with 12.3’s defaults for Snapper).

How do you set the time for the cron job? I haven’t so far, and it runs
daily most of the time since Snapper’s script is in /etc/cron.daily, but
not always at the same time of day. However, that depends on system up
times and when that cron job was last run wrt date and time. At least
that’s what I read re cron jobs generally, and the script doesn’t appear
to control the time it’s run.

Hi
It doesn’t seem to pick up the earlier ones (well it didn’t for me), you
can set the daily time via YaST sysconfig editor system->cron.

If home isn’t excluded (as we have discovered) and present on / doesn’t
seem to take much to fill it. Or maybe have configured zypper to use
full rpm’s and keep etc. I think for desktop use some planning is
required, for a server, well probably different esp snapshots etc.


Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
openSUSE 12.3 (x86_64) GNOME 3.8.4 Kernel 3.7.10-1.16-desktop
If you find this post helpful and are logged into the web interface,
please show your appreciation and click on the star below… Thanks!

On Thu, 17 Oct 2013 12:46:02 GMT
nrickert <nrickert@no-mx.forums.opensuse.org> wrote:

>
> Cloddy;2591745 Wrote:
> > I then stopped for a think. I’d also got Ethernet connection to work
> > ‘out of the box’ so to speak on a different machine.
>
<snip>
> My main point here, is that “btrfs” might not be the cause of your
> problem.
>

You may be right, but I can’t think what else it could be as, for me,
‘btrfs’ root partition is the only difference between failure and
success. I was only using a single internal drive and the same root
partition. Only real oddity with my system is that I have a
separate /tmp partition. Don’t know why that should matter but I think
I’ll try btrfs without that possible issue.

Sorry for late reply but I see I must have hit ‘ignore thread’ button
instead of ‘watch’! Not sure whether that’s down to my failing
eyesight, a senior moment, or both.


Graham P Davis, Bracknell, Berks.
openSUSE 13.1-RC1 (64-bit); KDE 4.11.2; AMD Phenom II X2 550 Processor;
Kernel: 3.11.6; Video: nVidia GeForce 210 (using nouveau driver);
Sound: ATI SBx00 Azalia (Intel HDA); Wireless: BCM4306