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

31–40 of 240 posts

Re: Five Years of Btrfs

#31

Post by InTheArena »

I went on a quest a few years ago, thinking it would be good for the industry to standardize on a single next generation filesystem for UNIX. I started with ZFS on linux since that seemed to have the most vocal advocates. That lasted about a half year, until a bug in the code resulted in a completely corrupt disk, and I had to restore 4TB of data over a month from offside backups. That plus the licensing confusion around ZFS has made it impossible for ZFS to be the defacto choice.

I went down the BTRFS path, despite it's dodgy reputation when netgear announced their little embedded NASes, and switched my server over to it. The experience was solid enough that I bought high-end synology and have had zero problems with it.

Re: Five Years of Btrfs

#32

Post by cyphar »

alyandon wrote: post #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.

You can grow and add/remove raid1 devices (mirror vdevs) in ZFS without any significant work or downtime. Shrinking does require a bit more work, but depending on your setup it can be done fairly painlessly with send/recv (and shrinking is usually not something which is a very common administrative operation).

Re: Five Years of Btrfs

#33

Post by ak217 »

lousken wrote: post #7

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

At a previous job, I deployed btrfs to production in a system that continuously spins up and shuts down thousands of VMs. A key feature that I was able to leverage to make this easy is seed devices. This btrfs feature works similarly to overlay filesystems.

If I were doing that today, I would do a bake-off of OverlayFS vs. btrfs for this feature. Btrfs has many other compelling features that may make it worth using, although it's always been slower than ext4/xfs so I'd also need to check how it does with modern ultra high performance NVMe drives.

Btrfs never lost our data, although there was a kernel panic in the journal writing code in the Linux 3.2/Ubuntu 12.04 timeframe. The panic would not cause data loss but it did wedge VMs. Since that was fixed, it's had a 100% reliable run in that system, to my knowledge.

Re: Five Years of Btrfs

#34

Post by InTheArena »

barclay wrote: post #21
agravier wrote: post #14

Earlier quoted context omitted.

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...)

Not modifications per se, but it doesn't quite do the "normal" setup. Encryption is a mess (you can't export encrypted volumes via NFS), and the caching layer on top of it seems prone to corruption on the SSD (I've had my NVMe mirror cache drop twice over the last year and a half).

I'd like to see them move to full disk encryption rather then their current approach.

Re: Five Years of Btrfs

#35

Post by _jal »

nickik wrote: post #28
_jal wrote: post #22

Earlier quoted context omitted.

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.

I don't disagree that maintainer-goals and practices make me trust ZFS more. They do. But there have been bugs. Last major one I remember in the core code is this one:

https://blog.lastinfirstout.net/2010/04/bit-by-bug-data-loss...

But there was a Linux-specific data loss bug with ZFS in 2018:

https://github.com/zfsonlinux/zfs/issues/7401

Of course you should use what you like. And I agree that ZFS is safer. But again, I don't know of any file system that can say it has "been stable from the beginning", if stable means no data loss.

Re: Five Years of Btrfs

#36

Post by rrauenza »

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…

I've also been running btrfs (on CentOS7) for about five years on my home NAS.

One advantage is it detects bit rot -- and you can scrub the disks once a week looking for the bad blocks.

I also like the inline compression.

I run at RAID1 and the only issue I had was several years ago there was a bug about freeing allocations so occasionally the filesystem would be full but not full.

Re: Five Years of Btrfs

#37

Post by geophertz »

Is using btrfs on a personal machine something to do? It seems that all the comments as well as articles about it, just assume you're running it on a server.

The ability to add and remove disks on a desktop machine is very tempting.

Re: Five Years of Btrfs

#38

Post by loudmax »

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 think its much more NIMBY then a license issue

How do you propose that ZFS be brought into Linux? When Sun released ZFS as open source, they made a deliberate decision to use a license that prevented it from being integrated into the Linux kernel. This was no accident. At the time, Sun was still pushing OpenSolaris which was losing ground to Linux. The ZFS on Linux project gets around this restriction by running ZFS in user space, but this is not optimal.

You can make a legitimate argument that Linux should have been released under a BSD style license (I think that would be wrong, but it's plausible). I don't see how you can argue that ZFS's license is somehow the fault of the Linux world.

Re: Five Years of Btrfs

#40

Post by StreamBright »

derefr wrote: post #27

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…

>> 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)?

As far as I know AWS does not use SANs because they consider it as anti-pattern. Most backups land on S3 because of reliability and price.

Post reply on HN