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

51–60 of 240 posts

Re: Five Years of Btrfs

#51

Post by abotsis »

abotsis wrote: post #48

It’s worth noting that much of the premise of the article (wanting flexibility) is outdated. Zfs has support for removing top-level raid 0/1 vdevs now. So you can take a raid10 pool, and remove a top level mirror vdev completely. Note that this doesn’t work for raid5/6 vdevs, but as the author points out, those are becoming less and less used because of rebuild time and performance. In addition to the slew of other f…

*Just kidding on send/recv, looks like it’s there now. Substitute with encryption if you need another example.

Re: Five Years of Btrfs

#52

Post by zerkten »

ailideex wrote: post #5
e40 wrote: 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?

It's the default for new Synology devices, and has been for a while. I suspect others are using it in a similar situation for home-grade NAS and up into the prosumer end of the market.

I feel like Btrfs is probably going to be well tested here, but I wonder how many of these users are diagnosing Btrfs problems when they occur? It's going to be more evident to some people, and you have to assume that some of the vendors are competent, but this is against a backdrop of people throwing this kit away or starting from scratch versus performing a root cause analysis.

I've personally been running this since it was stable on my DS1515+. I haven't had filesystem issues yet, but I make sure my important stuff is backed up elsewhere. A local backup like this is convenient for faster recovery in a lot of situations though which is why I keep it. I've SSH'd to the device and played around a little, but I fear I'd hit something proprietary, if the worst recovery situation occurred and I had to get everything from the DS1515+. If it was just an Ubuntu box I wouldn't have those fears, but the Syno NAS package is compelling.

Re: Five Years of Btrfs

#53

Post by xzcat »

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

I'll throw in my own anecdote. ZFS on root caused me a significant amount of headache when the proxmox node I was using it on just randomly decided it wasn't going to boot anymore. The ZFS pools were fine, no data was lost, but no amount of messing with it fixed the zfsonroot and it was quite difficult to find quality search results for.

And of course it was a weekend where my parents and siblings and in-laws were visiting, so I had the joy of going around messing with DNS settings wherever someone had a device that only paid attention to the first two DNS servers in the DHCP settings.

(I've since changed my DNS setup- now I only have a primary self-hosted one that's on an RPi in my networking cabinet, and the second entry is Google. I figure if I only get two servers that are respected for real, I'm making sure one of them is google.)

Re: Five Years of Btrfs

#54

Post by derefr »

polskibus wrote: post #47
StreamBright wrote: post #40

Earlier quoted context omitted.

>> 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 pric…

So how is S3 implemented? Does it reuse any publicly available open source component?

I don’t think they’ve published anything specifically on S3’s architecture (someone please correct me if I’m wrong, I last looked into this a long time ago), but

1. they came out with S3 soon after coming out with their Dynamo paper (before releasing DynamoDB, even); and

2. there’s a good constructive proof, as a studyable FOSS system, for how to build object storage on top of a Dynamo architecture, in the form of Riak CS (object storage) which is built atop Riak KV (a Dynamo impl.) Riak CS seems to make pretty much the same set of guarantees (in terms of time/space complexity of operations, possible durability numbers per scaled number of copies, etc.) that S3 does, so it’s a fair guess that they’re similarly-architected systems.

Re: Five Years of Btrfs

#56

Post by 3fe9a03ccd14ca5 »

jxcl wrote: post #43
pantalaimon wrote: post #39

Earlier quoted context omitted.

> nowadays that it's reliability issues have been fixed Is this also true for RAID5/6?

This issue has its own wiki page on the BTRFS wiki: https://btrfs.wiki.kernel.org/index.php/RAID56 So, no, that particular issue hasn't been fixed.

> * For data, it should be safe as long as a scrub is run immediately after any unclean shutdown.*

That’s unfortunate. Does the scrub run automatically in those situations? Consumer hardware will be the most prone to intermittent power failure.

Re: Five Years of Btrfs

#57

Post by trasz »

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

On the other hand, choosing to use GPL would prevent it from being integrated anywhere else. You'd also lose the patent protection granted by CDDL.

Re: Five Years of Btrfs

#58

Post by jolmg »

xorcist wrote: post #15
curt15 wrote: 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.

You can also set such an attribute on files and subvolumes in btrfs.

https://wiki.archlinux.org/index.php/Btrfs#Disabling_CoW

Re: Five Years of Btrfs

#59

Post by zielmicha »

fsync is still a bit slow on BTRFS (on ZFS too, but to a smaller degree). For example, I just did a quick benchmark on Linux 5.3.0 - installing Emacs on fresh Ubuntu 18.04 chroot (dpkg calls fsync after every installed package).

ext4 - 33s, ZFS - 50s, btfrs - 74s

(test was ran on Vultr.com 2GB virtual machine, backing disk was allocated using "fallocate --length 10G" on ext4 filesystem, the results are very consistent)

Re: Five Years of Btrfs

#60

Post by vetinari »

InTheArena wrote: post #34
barclay wrote: post #21

Earlier quoted context omitted.

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

They do encryption/compression on subvolume level; each share you create is a separate subvolume.

For RAID5, they are using it on top of LVM, but with some modification - the synology implementation hooks LVM and btrfs together, so it gets ZFS-like properties.

There's a guy on the internet, who was playing around with it: https://daltondur.st/syno_btrfs_1/

Post reply on HN