Btrfs Getting RAID 5/6 Fixes In Linux 4.12 Kernel

[TheBlackCat]

Is anyone using BTRFS in production? How are the experiences?

openSUSE uses it by default on the root partition due to the subvolume support. I have had no problems with it once I turned off openSUSE's snapper which eats all my hard drive space. That isn't the fault of BTRFS, though, snapper just made snapshots of every update without any concern for how much hard driver space they used.

Note that this is on the root partition, which is easy to reinstall if things were to get bad (they haven't for me AFAIK). The home partition uses XFS by default though I use EXT4 since I don't want to risk changing the partition format on existing data.

[marciosr]

I've been using Btrfs on a notebook and a PC. I use autodefrag, subvolumes and compression. My Arch instalations have 3 ~ 4 years. I do not use raid and I have tow backups on external disks with ext4. I'm not having problems or data lost with btrfs. I mostly use the last kernel stable and sometimes lts, sometimes I test kernel mainline.

But if I have problems and can't use subvolumes and compression, there aren't reasons to use btrfs. I will prefer ext4 or xfs.

[starshipeleven]

openSUSE uses it by default on the root partition due to the subvolume support. I have had no problems with it once I turned off openSUSE's snapper which eats all my hard drive space. That isn't the fault of BTRFS, though, snapper just made snapshots of every update without any concern for how much hard driver space they used.

I have Snapper enabled since I installed Leap 42.1, and it has yet to eat all my drive space.
It's clearly auto-deleting snapshots as apart from the first one done on install I see snapshot number 959 to snapshot 1092 in the list (many snapshots are deleted in between these, it's a total of a dozen or so).

I heard that Snapper had these issues to the snapshot deleting algos but I thought they were fixed.

[caligula]

I use it for all my personal workstations with compress=lzo and such, since some months even with luks whole-disk encryption, …

https://www.youtube.com/watch?v=D3H8GrVm_XI&feature=youtu.be&t=14m20s

The only problem I encountered were some FS damage after mourning external SSD on a big-endian PPC while it was otherwise only used on x86 systems. I noticed btrfs IRC, but got no response, ... guess everyone is on x86, or otherwise little endian now anyways.

Will probably start to move some light web servers et al. over to btrfs compress=lzo soon, too.

The problem with lzo is speed. lz4 has similar efficiency while working a lot faster. The decompression speed is 300% higher https://github.com/lz4/lz4

[torsionbar28]

I use it for all my personal workstations with compress=lzo and such, since some months even with luks whole-disk encryption, …

https://www.youtube.com/watch?v=D3H8GrVm_XI&feature=youtu.be&t=14m20s

The only problem I encountered were some FS damage after mourning external SSD on a big-endian PPC while it was otherwise only used on x86 systems. I noticed btrfs IRC, but got no response, ... guess everyone is on x86, or otherwise little endian now anyways.

Will probably start to move some light web servers et al. over to btrfs compress=lzo soon, too.

Isn't ARM big endian? Or at least it supports both modes?

[jacob]

Does anyone using btrfs on desktop? I'm thinking about using it on my primary desktop (snapshots - great feature), but I'm a bit worried about my datas. Does btrfs is safe to use today?

I'm using it on all my desktops and laptops with Ubuntu. It's a breeze, personally not only I never had any priblem with it but it's the first FS that has been 100% reliable for me - I've had corrupted FSes with XFS and Ext4 in the past. Mind you I'm not using RAID 5/6, but I'm doing some kernel development with all the crashes and savage reboots that it entails

Btrfs is also particularly asesome with LXD. The only downside is that you better enable "force-unsafe-io" in dpkg (otherwise it's extremely sliw) and if you use VMs with virtual disk images (vmdk, qcow2 etc) you need to switch off COW on these files or actually on the dir where they are located.

[pcxmac]

I'm a former everyday btrfs user. The main reason I started using btrfs was that compress=lzo seemed useful to decrease wear and tear on my SSD's. Why I switched to XFS after two years is mainly because of this irritating bug: http://marc.merlins.org/perso/btrfs/...-Problems.html

The bug still hasn't been fixed and it required me to waste time 1-2 times per month running the workaround described on the website I linked above. I didn't suffer any dataloss nor any unrecoverable errors of any kind, though I used it on a single disk and never in any RAID mode.

I am using BTRFS except in cases where I use ZFS on spinning rust. Funny thing is I have never lost data on BTRFS, be it on large 12-16 SSD arrays (raid5/6) or RAID0 or RAID1 configurations, while I have lost two pools under ZFS (once when etc got deleted and took the writes with it, and once when I mistakenly upgraded my kernel (and didn't regress), but I could rebuild that one from other sources). ZFSOL is okay, but it's not nearly as intuitive or capable as BTRFS. ZFS also tries to do more than it should.

Right now I run 4 drives striped (no redundancy), but I am able to properly backup, no issues, and I push my capacity limits to with in 10GB of completely full, even down to a few hundred MBs on a few occasions. BTRFS used to have issues reporting actual size, but I don't know that is the case anymore, I also have several subvolumes and snapshots on that striped array.

[pcxmac]

The problem with lzo is speed. lz4 has similar efficiency while working a lot faster. The decompression speed is 300% higher https://github.com/lz4/lz4

lz4 works great when you have plenty of RAM, but on smaller machines like embedded systems, with slower processors, lzo is the better choice.

[Zucca]

Does anyone using btrfs on desktop? I'm thinking about using it on my primary desktop (snapshots - great feature), but I'm a bit worried about my datas. Does btrfs is safe to use today?

I have btrfs on my desktop. Spread over six SSDs on raid10 mode. Rescently systemd had once again some problems hibernating the system and I had to do a cold reset. I also have strugled with SATA controller causing errors. That time I thought btrfs would give up. Suprisingly it survived.
Filesystem got many minor errors (obviously), but every time a simple filesystem scrub fixed all the errors.
Am I satisfied how btrfs operates? Considering how flexibly it takes all the different sized disks and has a plethora of nifty features and so far it has been able to correct thousands of errors resulted from cold reset and faulty SATA controller... Yes. I'm damn satisfied how it works.
In addition to snapshotting I still keep seperate backups on my home server.

I may be one of the lucky ones, so better to read how other users have experienced their btrfs.

[DrYak]

lz4 works great when you have plenty of RAM, but on smaller machines like embedded systems, with slower processors, lzo is the better choice.

I doubt you'll use something like BTRFS on a tiny RAM starved embed device. The smallest device I can think of is still a smartphone with 1G RAM (Jolla's phone).
So LZ4 memory usage doesn't sound problematic to me.

Isn't ARM big endian? Or at least it supports both modes?

As far as I've understood: ARM is *bi*-endian : can do either endianness, but most of the time Linux on ARM runs in little endian mode.
So BTRFS in a Jolla phone still runs in the same endianness as on Intel.

Why I switched to XFS after two years is mainly because of this irritating bug: http://marc.merlins.org/perso/btrfs/...-Problems.html
The bug still hasn't been fixed and it required me to waste time 1-2 times per month running the workaround described on the website I linked above.

That isn't even as much a bug as the fact that the stripe allocation in BTRFS is really weird for somebody not used to it:

Simpler file systems that are only file system allocation files one extent at a time. ZFS and BTRFS are whole stacks, that also handle stripe allocation in blocks of 1GiB (for data. It's smaller for metadata.) So you system might need to allocate a new stripe to write more data to it, but can't anymore even if the data doesn't fill up the whole volume yet (the thing which is actually failling is the equivalent of a "lvextend" in the more classical MDRAID / LVM /EXT4 stack)

In addition, BTRFS, ZFS, UDF, F2FS and similar are copy-on-write (or log structured, resp.) filesystem. They NEVER overwrite data.
They always write new copy of the data, then update pointer to point to the new copy.
So on all these system, even *deleting* data consumes space (at least transiently until unused space gets garbage collected).

This *is being* mitigiated as of late :
- more recent version of BTRFS can auto-labance a bit to some extent.
- for quite a number of recent versions, BTRFS does reserve space to handle deletion (same bug was also fixed with UDF)
- most of the distro who use BTRFS as a default filesystem (suse, jolla's sailfish os) come with tools (suse: btrfs-maintenance, sailfishos: btrfs-balancer) to automate the house-keeping of BTRFS partitions (scrubbing for errors, balancing to free 1GiB blocks), so there it is more set and forget.

Also note that, because it's not the whole disk which gets striped like in mdadm's raid, but each invididually allocated 1GiB stripe, BTRFS' RAID1 isn't as efficient to load balance between RAID1 copies to gain 2x when reading (each 1GiB stripe is allocated as you go, and it needs extra code to decide which copy of which stripe shares disk with other stripes).
(mdadm: all copies #1 go do disk #1, all copies #2 go to disk #2. btrfs: copy #1 of first 1GB blck might by on disk #1, but next block might have it's copy #1 on disk #3).

Is anyone using BTRFS in production? How are the experiences?

Using it all the way from my smartphone (Jolla) through my laptop and workstation up to servers.
Very happy with it.
Never ran into a problem for the past 2 years (once I got the basics understood), despite powerfailures, etc.

Sailfish OS on Jolla smartphone.
Suse on laptop (tumbleweed) and workstation (leap)
debian, centos, etc. on numerous servers.

1. Stay with RAID1 mode only.
2. Have at least 3x disks available. You need at least two working devices always or else BTRFS could get stuck in read only mode forever!
3. Avoid using compression, autodefrag, snapshots and/or lots of subvolumes
4. Keep an eye on the output of "btrfs filesystem usage -T /mountpoint" and rebalance if the unallocated count is low on any of the devices
5. Keep an eye on the output of "btrfs device status /mountpoint" if you have read/write and/or corruption errors.
6. As with all filesystems have recent, tested, working backups!
7. Keep an eye on the status page and mailing list and stay on a LTS kernel unless there are strong reasons to upgrade.

1. I second that : RAID5/6 still aren't completely ready, they still can't handle bitrot.
2. --- not necessarily. bugs have been fixed and distros have tools to automate the maintenance to avoid that.
3. --- that's the whole point of BTRFS. Actually if you maintain your BTRFS properly (or actually use tools for that). Compression and specially snapshots are nice tools.
I would more say : stay within known parameters.
Thus do not use RAID5/6 (yet), do not tweak it un-necessarily (e.g.: no need to modify nodesize - makes scrubing compressed data less reliable).
4. --- or use a distro which has tools for that (e.g.: suse's btrfs-maintenance, sailfish's: btrfs-balancer)
5. --- which should be caught by the above tools too.
6. I second that. Keep backups no matter what. And actually BTRFS on your fileserver makes making backups easier (thanks for rsync+snapshots, instead of playing with rsanc+hardlinks)
7. --- well nowadays, btrfs has quite stabilized. You aren't in for bad surprises if you stay within stable features (no RAID5/6 yet).

Again, I have no problem, BUT I tend to use distro which have tools (on suse and sailfish) or roll my own solution (on debian).