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

Examining Btrfs

arstechnica.com

Post reply on HN
Print view View original

21–30 of 112 posts

Re: Examining Btrfs

#21

Post by mnw21cam »

terrywang wrote: post #10

Btrfs is flexible and works well for self-hosted home storage use cases, especially running cheap hardware & HDDs with mixed RPM + capacity specs (many consider it a major advantage over OpenZFS on Linux which inherits ZFS pros and cons). As far as data corruption is concerned, avoid using raid{5,6} profile (that governs how a chunk is replicated within or across a member device) for data and you should be fine. Runn…

I use ZFS on my main computer, but it sends its backups to a tiny computer with two laptop USB drives plugged in, running Btrfs RAID-0. (The second drive was added when the first one filled up.) I did it that way because it's the second copy of the data, and I'll only need to call on it if my main computer dies. I have a sentry program running on the tiny computer that regularly checks that all the data is present, correct, and readable. The likelihood that it breaks at the same time as my main computer is slim.

I wouldn't trust Btrfs for much more than that.

I specified ZFS for some of work's very large servers (>100 drives). They wanted to do hardware RAID and XFS instead, and I can just image the nightmares that would have involved.

Re: Examining Btrfs

#22

Post by creshal »

uniqueuid wrote: post #12

TL;DR: Btrfs is usable in mirror mode. Raid is still unusable (as in: you will lose data) Usage and tooling are unintuitive and dangerous. I have to say, it doesn't sound so bad when you know what you're doing. The example from the article - the fact that you need to re-silver and re-balance a mirror after a failure - yes that is dangerous. But then again, when you're starting with zero ZFS knowledge, you also need t…

> But then again, when you're starting with zero ZFS knowledge, you also need to learn the particular way it's designed.

Except… there's nothing to really learn. All these weird edge cases that can kill your BTRFS simply don't exist in ZFS. The tooling is also much more polished and in the few cases that something does require user attention, it'll tell you in easily understandable terms, so as a new user the only command you really need to learn is `zpool status`, which you now did.

Re: Examining Btrfs

#24

Post by uniqueuid »

zionic wrote: post #20
uniqueuid wrote: post #8

One thing I always found curious is that Synology supports Btrfs. Granted, they are not exactly what I'd call a company with a rock-solid track record, but they are still a rather large premium manufacturer in the NAS space. It seems they have either managed to contain Btrfs' complexity and prevent users from doing the dangerous things, or their own hybrid raid was even worse, or they are just very risk friendly.

I’ve been incredibly happy with my Synology products FWIW. BTRFS/SHR have been rock solid.

The hardware is very nice indeed, and the software is smooth as well.

What has irritated me in the past was that they sometimes took very long to fix vulnerabilities [1].

[1] https://www.cvedetails.com/vendor/11138/Synology.html

Re: Examining Btrfs

#25

Post by naranha »

mnw21cam wrote: post #21
terrywang wrote: post #10

Btrfs is flexible and works well for self-hosted home storage use cases, especially running cheap hardware & HDDs with mixed RPM + capacity specs (many consider it a major advantage over OpenZFS on Linux which inherits ZFS pros and cons). As far as data corruption is concerned, avoid using raid{5,6} profile (that governs how a chunk is replicated within or across a member device) for data and you should be fine. Runn…

I use ZFS on my main computer, but it sends its backups to a tiny computer with two laptop USB drives plugged in, running Btrfs RAID-0. (The second drive was added when the first one filled up.) I did it that way because it's the second copy of the data, and I'll only need to call on it if my main computer dies. I have a sentry program running on the tiny computer that regularly checks that all the data is present, c…

What is kind of neat for your case maybe is that you can run btrfs scrub even on raid0 or a single drive. The scrub command reads the whole filesystem and verifies checksums, so you can be sure that the data is readable and correct.

Disclaimer: I only tried it on a single disk.

Re: Examining Btrfs

#27

Post by creshal »

uniqueuid wrote: post #6
nikbackm wrote: post #3

Earlier quoted context omitted.

What about ZFS?

I have to second this - the rampant layering violation that is ZFS has in my experience been extremely robust. Maybe it's simply doing the "one coherent tool to manage large chunks of data and disks" thing well.

"Do only one thing and do it well" is highly dependent on how you define "thing", yes.

Is awk bad because you can't compose the internals of its built-in functions? Are vim and emacs bad because they have multiple modes of operation? Is bash violating the unix spirit by doing both the job of an interactive shell and a C API extensible scripting engine?

I don't think so.

ZFS, BTRFS, and advanced ext4 features like encryption are more arguments that layered block devices may have been a poor choice of abstraction.

Re: Examining Btrfs

#28

Post by WastingMyTime89 »

creshal wrote: post #22
uniqueuid wrote: post #12

TL;DR: Btrfs is usable in mirror mode. Raid is still unusable (as in: you will lose data) Usage and tooling are unintuitive and dangerous. I have to say, it doesn't sound so bad when you know what you're doing. The example from the article - the fact that you need to re-silver and re-balance a mirror after a failure - yes that is dangerous. But then again, when you're starting with zero ZFS knowledge, you also need t…

> But then again, when you're starting with zero ZFS knowledge, you also need to learn the particular way it's designed. Except… there's nothing to really learn. All these weird edge cases that can kill your BTRFS simply don't exist in ZFS. The tooling is also much more polished and in the few cases that something does require user attention, it'll tell you in easily understandable terms, so as a new user the only co…

> Except… there's nothing to really learn.

Would you mind explaining to us how to add a disk to an array with ZFS? Then same question but with a disk which is not the same size that the rest of the array.

Re: Examining Btrfs

#29

Post by uniqueuid »

creshal wrote: post #22
uniqueuid wrote: post #12

TL;DR: Btrfs is usable in mirror mode. Raid is still unusable (as in: you will lose data) Usage and tooling are unintuitive and dangerous. I have to say, it doesn't sound so bad when you know what you're doing. The example from the article - the fact that you need to re-silver and re-balance a mirror after a failure - yes that is dangerous. But then again, when you're starting with zero ZFS knowledge, you also need t…

> But then again, when you're starting with zero ZFS knowledge, you also need to learn the particular way it's designed. Except… there's nothing to really learn. All these weird edge cases that can kill your BTRFS simply don't exist in ZFS. The tooling is also much more polished and in the few cases that something does require user attention, it'll tell you in easily understandable terms, so as a new user the only co…

Sure, I give you that ZFS' tooling is much, much more polished.

But of course there are peculiarities that have 'bitten' people (softly) in the past:

- dedup has hardly any use case, novices get enticed to try something that doesn't do what they think it does

- ZIL and SLOG sound like "a simple cache" when in reality they are much more complex

- You can add single devices to a (redundant) pool, at which point you've lost redundancy, perhaps without knowing.

- No defrag

- No re-balance

- No growing pools

- ARC still surprises people (also, I've had kernel crashes under heavy load when the ARC didn't free ram fast enough ... edge case maybe, but still)

That said, of course, ZFS is awesome and I encourage everybody to give it a try.

Re: Examining Btrfs

#30

Post by EastToWest »

DiabloD3 wrote: post #19

Brtfs only exists as Oracle's "replacement" for ZFS, to hedge their bets in case they couldn't buy Sun. Oracle bought sun in 2010, that has been 12 years. They merged the Btrfs and ZFS teams, they then worked on ZFS entirely with no Btrfs work, and then basically reassigned, fired, or otherwise dissolved the ZFS team when it became clear that OpenZFS (Sun's chosen steward for ZFS) could not be swayed. Btrfs has had n…

> Btrfs has had no real work done on it since then, and anyone that is actually serious about data storage has moved to ZFS, or has left POSIX filesystems entirely.

I'm not very familiar with this space, but if this were true why would Fedora use Btrfs by default?

Also on Fedora wiki [0] -- Btrfs is a mature, well-understood, and battle-tested file system, used on both desktop/container and server/cloud use-cases -- which seems to contradict what you said.

[0] https://fedoraproject.org/wiki/Changes/BtrfsByDefault

Post reply on HN