Live data from Hacker News

Examining Btrfs

arstechnica.com

1–10 of 112 posts

Re: Examining Btrfs

#5
post #3

Do one thing and do it well. Do too much and you may end up like Btrfs.

What about ZFS?

Suspect as well --- for the same reason.

System level data handling functionality is critical and needs to be rock solid. Complexity makes this more difficult to achieve. Not to say it's impossible, just increasingly more difficult.

Re: Examining Btrfs

#6
post #3

Do one thing and do it well. Do too much and you may end up like Btrfs.

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.

Re: Examining Btrfs

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

Re: Examining Btrfs

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

Running OpenZFS on Linux also requires dealing with DKM(ES)S, Ubuntu being an exception (hmm)...

NOTE: Self-hosted podcast show episode 25 contains excellent coverage (ZFS vs. Btrfs) by Jonathan Panozzo from Unraid.

Post reply on HN