Live data from Hacker News

Five Years of Btrfs

markmcb.com

11–20 of 240 posts

Re: Five Years of Btrfs

#11
post #7

Did anyone had the courage to use btrfs in production? Any stories to share?

Seems like Facebook uses it:

"Btrfs has played a role in increasing efficiency and resource utilization in Facebook’s data centers in a number of different applications. Recently, Btrfs helped eliminate priority inversions caused by the journaling behavior of the previous filesystem, when used for I/O control with cgroup2 (described below). Btrfs is the only filesystem implementation that currently works with resource isolation, and it’s now deployed on millions of servers, driving significant efficiency gains."

https://engineering.fb.com/open-source/linux/

Re: Five Years of Btrfs

#12
post #3

Love using Btrfs; the is no better filesystem than it nowadays that it's reliability issues have been fixed.

I tend to agree with you here -- reliability has been a non-issue for me, though I've never configured `btrfs` in its RAID configuration.

Performance becomes an issue in certain cases, but in every one that I've encountered, adjusting configuration has resolved the problems to my satisfaction.

Would my Windows 10 VM run better under a different filesystem, rather than `btrfs` with various tweaks applied? Reading relatively recent articles on the subject would suggest that it would, however, I'd rather work with a single filesystem type and understand its strengths/weaknesses than manage two different filesystems as long as I can get performance to a usable state.

Re: Five Years of Btrfs

#13
post #5
post #2

I've heard a lot of people say they won't use Btrfs due to reliability. Would have been nice to see that addressed.

What about the reliability? Are many people losing data with Btrfs?

Caveat: I don't use RAID[0].

In about 4 years of running it on a couple of servers and countless virtuals/desktops, I've never had a reliability issue that was directly related to btrfs. I do not have my servers plugged in to UPSes, I have the occasional "shutdown due to power loss". The only time I've lost data has been due to cable disconnection in my hardware RAID array, and even then I was able to recover a substantial amount of its `btrfs` stored files.

[0] Well, not filesystem-provided RAID; I have LSI controllers that provide the array to the OS as a single disk.

Re: Five Years of Btrfs

#14
post #7

Did anyone had the courage to use btrfs in production? Any stories to share?

It's the default on recent Synology NAS, in my experience. No particular issue in my limited experience. Mostly transparent for the user.

Re: Five Years of Btrfs

#15
post #4

BTRFS is well known for being ill-suited to VMs or databases. How come ZFS doesn't have that reputation?

There is an attribute called NOCOW that can be set on specific files that should not be copy-on-write, which is what messes with databases, filesystem images and other things that needs fast in-place updates.

It can also be a set as a flag on subvolumes.

Re: Five Years of Btrfs

#16
post #4

BTRFS is well known for being ill-suited to VMs or databases. How come ZFS doesn't have that reputation?

I think ZFS was just ahead. We considered btrfs many years ago to serve up VM's for ESX via NFS, but it just wasn't as performant unless you ran in async mode which jeopardized data integrity. ZFS let you introduce SSD-based ZIL and L2ARC caching which made performance totally fine in sync mode.

We're mostly NetApp AFF these days, but early on had close to a petabyte of ZFS-based storage power VM's on SuperMicro or Dell gear. Definitely was higher touch than NetApp but far less expensive.

Re: Five Years of Btrfs

#17
I use btrfs in raid1 mode and the ability to shrink/grow/add/remove devices at will without data loss or extended downtime led me to choose btrfs over zfs on my home servers.

Re: Five Years of Btrfs

#18
Being 'The Dude' of file system is literally the opposite of what I want. When looking at ZFS talks and the incredible complexity of some of those operations that Btrfs seems to think are 'no big deal', I will simply not trust that. Specially because it has been proven over and over again that Btrfs claims its 'stable' and then a new series of issues show up. Or its 'stable' but not if you use 'XY feature', or if the disk is 'to full' or whatever.

I remember using it after I had heard it was 'stable' and it eat my data not long after (not using crazy features or anything). I certainty will not use it again. A FS should be stable from the beginning, as stable core that you can then build features around, rather then a system with lots of feature that promises to be stable in a couple years (and then wasn't years after being in the kernel already).

Using ZFS for me has been nothing but joy in comparison. Growing the ZFS pool for me has been no issue at all, I never saw a reason why I would want to reconfigure my pool. I went from 4TB to 16TB+ so far in multiple iterations.

Overall not having ZFS in Linux is a huge failure of the Linux world. I think its much more NIMBY then a license issue.

Re: Five Years of Btrfs

#19
post #5
post #2

I've heard a lot of people say they won't use Btrfs due to reliability. Would have been nice to see that addressed.

What about the reliability? Are many people losing data with Btrfs?

My understanding is most bugs are ironed out of btrfs itself, but tooling is still weak. For example, if you have a disk drive go bad on you and you manage to recover ~ half of the sectors with a disk imaging tool, you won't be able to extract files from the image without extreme effort.

Re: Five Years of Btrfs

#20
post #5
post #2

I've heard a lot of people say they won't use Btrfs due to reliability. Would have been nice to see that addressed.

What about the reliability? Are many people losing data with Btrfs?

As best I can tell, reports of data loss on btrfs are all from the early 20-teens; after about 2014 or so I can't find anyone who claims to have lost data due to a btrfs bug on an up-to-date system.
Post reply on HN