Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Five Years of Btrfs

markmcb.com

Post reply on HN
Print view View original

21–30 of 240 posts

Re: Five Years of Btrfs

#21

Post by barclay »

agravier wrote: post #14
lousken wrote: 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.

(also a happy syno user here, been using it on several NAS's quite happily).

My rough understanding is synology did some pretty heavy modifications to btrfs in their implementation though... (a quick google finds me nothing to back this up, but i remember reading about it somewhere...)

Re: Five Years of Btrfs

#22

Post by _jal »

nickik wrote: post #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…

I mostly agree, and that's largely why I use ZFS a lot. But:

> A FS should be stable from the beginning,

If this is your standard, I don't think there's a file system out there that meets it. ZFS has had data-loss bugs. I doubt there is any non-toy file system that hasn't.

I've thought about what standard should apply to this - it is a prove-a-negative problem, that filesystem-X in combination with whatever recent kernel will not lose data. I don't have a good answer, but the one I came up with is "multiple years without a dataloss bug, of quick turnaround to other bug fixes, and a warm-fuzzy feeling about the developers."

Re: Five Years of Btrfs

#23

Post by alexgartrell »

jhalstead wrote: post #11
lousken wrote: 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 resourc…

Yeah there are a remarkable set of container runtime tasks (package downloads, rootfs creation and management, etc) that are way easier with btrfs. It wasn’t always smooth sailing but luckily Chris, Josef, Omar and others are awesome and now (and for the last while) we are asking for features rather than fixes.

Re: Five Years of Btrfs

#24

Post by pmarreck »

pojntfx wrote: post #3

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

I have to beg to differ here as I had a different experience that I literally just posted about to Reddit yesterday

https://www.reddit.com/r/zfs/comments/eu1qsj/a_tale_of_two_f...

tl;dr Unbeknownst to me I had a bad drive cable for an external NVMe enclosure that was causing intermittent I/O errors (only during high drive utilization) that went undetected by BTRFS and slowly corrupted my drive, eventually leading to an unbootable and unrepairable system (and to be fair, I should have scrubbed instead of attempting btrfsck --repair from another booted drive, but I don't care what you say, a --repair function should NOT potentially cause FURTHER corruption if it is at all available in the tooling! Like, just fucking rip it out if it can potentially make things worse, or recode the damn thing to just act defensively... jeez)

Wiped the drive and started over with Ubuntu 19.10 and its new integrated ZFS on Root support... ZFS detected the IO issue pretty much instantly and prevented further errors by freezing I/O. Swapped the cable out during my troubleshooting and the issue went away. Also, drive is plenty fast, read test at 800MB/s

Re: Five Years of Btrfs

#25

Post by Shalle135 »

Is there any specific reasons to run btrfs over for example ext4? You can create/shrink/grow pools, create encrypted volumes etc by using LVM.

It all depends on the application but in the majority of cases the io performance of btrfs is worse than the alternatives.

Redhat for example choose to deprecate btrfs for unknown reasons while SUSE made it it’s default. The future of it seems uncertain which may cause a lot of headache’s in major environments if implemented there.

Re: Five Years of Btrfs

#26

Post by archi42 »

lousken wrote: post #7

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

At home: I'm running a RAID1 btrfs on my 12 disk cold storage (rackmount, SAS backplane, JBOD SAS controller). It has two new 4TB 24/7-rated SATA disks I got for that NAS, the rest is mostly salvaged from work (old drives, 500GB to 1TB). I had exactly the same selling point on btrfs as the author - I see a "huge" 7.8TB RAID1, and once it fills up I just swap an old disk (or two) for another 24/7 disk with decent TB/$.

At work: I was told our OpenSUSEs had some failures/data-loss, so we're not using the default btrfs on these. Though I don't know with what version that was (we migrated to OpenSUSE about 3 years ago).

Re: Five Years of Btrfs

#27

Post by derefr »

A question for HN: what filesystem and/or block-device abstraction layer would you use on a database server, if you wanted to perform scheduled incremental backups using filesystem-level consistent snapshotting and differential snapshot shipping to object storage, instead of using the DBMS’s own replication layer to achieve this effect? (I.e. you want disaster recovery, not high availability.)

Or, to put that another way: what are AWS and GCP using in their SANs (EBS; GCE PD) that allows them to take on-demand incremental snapshots of SAN volumes, and then ship those snapshots away from the origin node into safer out-of-cluster replicated storage (e.g. object storage)? It it proprietary, or is it just several FOSS technologies glued together?

My naive guess would be that the cloud hosts are either using ZFS volumes, or LVM LVs (which do have incremental snapshot capability, if the disk is created in a thin pool) under iSCSI. (Or they’re relying on whatever point-solution VMware et al sold them.)

If you control the filesystem layer (i.e. you don’t need to be filesystem-agnostic), would Btrfs snapshots be better for this same use-case?

Re: Five Years of Btrfs

#28

Post by nickik »

_jal wrote: post #22
nickik wrote: post #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…

I mostly agree, and that's largely why I use ZFS a lot. But: > A FS should be stable from the beginning, If this is your standard, I don't think there's a file system out there that meets it. ZFS has had data-loss bugs. I doubt there is any non-toy file system that hasn't. I've thought about what standard should apply to this - it is a prove-a-negative problem, that filesystem-X in combination with whatever recent ke…

It was designed to primary not lose data from the very beginning. That was at the very core of every design choice. Maybe there were a few such bugs but I have not read of any, while in comparison Btrfs I have read a whole of them.

Compare how bcachefs/zfs approaches these challenges and then go back to the early years of Btrfs. There is really no comparison.

Re: Five Years of Btrfs

#29

Post by boris »

lousken wrote: post #7

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

We (the build2 project) use it in our CI infrastructure for VM storage. For every build we make a snapshot of a VM, boot it, build, drop the snapshot, repeat. So we are talking about making/dropping snapshots every couple of minutes 24x7 for months without a reboot. We haven't had a single issue.

Re: Five Years of Btrfs

#30

Post by derefr »

Shalle135 wrote: post #25

Is there any specific reasons to run btrfs over for example ext4? You can create/shrink/grow pools, create encrypted volumes etc by using LVM. It all depends on the application but in the majority of cases the io performance of btrfs is worse than the alternatives. Redhat for example choose to deprecate btrfs for unknown reasons while SUSE made it it’s default. The future of it seems uncertain which may cause a lot o…

Redhat and SUSE (SLES) are both enterprise environments, so at every level, they have to choose one tech stack to go all-in on (i.e. to train their support staffs on), and then discourage their customers from using the others. (“Deprecating” a component, for such orgs, means that some of their customers are now stuck with it, and they’ll continue to support those customers in their use of it, but they certainly won’t support new customers using it.)

The fact that one enterprise-support provider went all-in on Btrfs, while another didn’t, basically tells you that the choice is pretty arbitrary. If no enterprise-support provider used Btrfs, then I’d be concerned.

Post reply on HN