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

31–40 of 112 posts

Re: Examining Btrfs

#31

Post by kloch »

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've used ZFS on FreeBSD for many years and it's absolutely rock solid. There was even a case where an IPMI had been hacked and the attacker reformatted the disks for Windows 10 and I was able to recover most of the the data. The attack was interrupted before they could copy data to the disk and I had left a small amount of space unallocated at the end of the disk.

Lessons learned:

- ZFS is very robust for handling partial corruption

- Always leave unallocated (~1gb) space before and after critical data partitions. accidental/malicious reformatting will likely use the entire disk so the new FS superblocks are less likely to overwrite all of the original ones.

- Always have an offline backup of your partition table in case of accitental/malicious repartitioning

The one thing that still makes me nervous is large stripes of mirrors where a multi-disk failure in one mirror can take out the entire stripe. For that reason I stick with simple 2 disk (or 3 disk for critical data) mirrors and avoid combining them in stripes.

Re: Examining Btrfs

#32

Post by naranha »

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

Apparently it used at facebook a lot too.

https://lwn.net/Articles/824855/

Re: Examining Btrfs

#33

Post by cvubrugier »

vanburen wrote: post #16
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 think Synology runs BTRFS on top of LVM, so that may mitigate some of the issues.

Synology SHR is btrfs (or ext4) on top of LVM and MD. MD is used for redundancy. LVM is used to aggregate multiple MD arrays into a volume group and to allow creating one or move volumes from that volume group.

Re: Examining Btrfs

#34

Post by uniqueuid »

WastingMyTime89 wrote: post #28
creshal wrote: post #22

Earlier quoted context omitted.

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

You're teasing, of course, but it shows the real problems.

To take you up on that with a dangerous example that reinforces the point:

To add a disk to an array whose used space is less than the capacity of a single disk, you can (DON'T DO THIS, IT'S DANGEROUS)

(1) remove a disk from the array (it's degraded now) (2) reformat the single disk, put all data on there (3) create a sparse file with the size of one disk (4) create a new array with N disks, in place of the temporary disk use the sparse file as a device (5) remove the sparse file (the new array is now degraded) (6) bring the new array up, copy all data from temp disk on it (7) replace the sparse file with the temp disk (8) copy files around to make them re-balance

Congratulations, you've now grown your array, and put your data seriously at risk in the process! :)

Re: Examining Btrfs

#35

Post by jcalvinowens »

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…

This is one of the most laughably ignorant posts I've ever seen on the internet.

> 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

Btrfs is the most actively developed filesystem in the kernel, both by LOC changed and the number of contributors. Facebook publicly stated that they run BTRFS on every webserver years ago.

ZFS is an antiquated joke. It is wed to the memory allocator in Solaris, and requires that you permanently reserve 1GB of RAM per 1TB of disk space, which is an impractical constraint in the modern world. ZFS is also full of cute little wasteful "innovations" like 128-bit file size support.

I don't know what planet you're from, but it's not mine :)

Re: Examining Btrfs

#36

Post by COGlory »

>Moving beyond the question of individual disk reliability, btrfs-raid1 can only tolerate a single disk failure, no matter how large the total array is. The remaining copies of the blocks that were on a lost disk are distributed throughout the entire array—so losing any second disk loses you the array along with it. (This is in contrast to RAID10 arrays, which can survive any number of disk failures as long as no two are from the same mirror pair.)

This feels a little disingenuous to me. This is a distinctly RAID-1 problem. This doesn't feel like a BTRFS problem. Everyone knows RAID-1 = 1 drive loss.

>I don't have anything specific to say about btrfs-raid0, other than the fact that it's raid zero. Any failure of any disk loses all data on the array. This is not a storage system, it's a virtual woodchipper. Avoid.

If the previous paragraph felt disingenuous, this one feels downright malicious. Not only does BTRFS RAID-0 have no differences from normal RAID-0, but the blanket recommendation to avoid it makes no sense. There are many use cases for RAID-0, but the author is acting like this is some kind of problem with BTRFS.

Re: Examining Btrfs

#37

Post by nimbius »

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

changelog seems to refute this point entirely.

https://btrfs.wiki.kernel.org/index.php/Changelog

>anyone that is actually serious about data storage has moved to ZFS

sometimes data storage doesnt have to scale, and thats okay. there are still plenty of use cases for lvm/xfs/mdadm in environments that dont need Google levels of service. im "serious" about data storage and run raid10 btrfs.

>or has left POSIX filesystems entirely.

oh get off the cross. redhat intentionally threw backing into XFS to make it functional with Ceph. just because BTRFS has issues with RAID5 (arguably the worst RAID) doesnt mean the whole of POSIX storage has been relegated to the ash heap.

Re: Examining Btrfs

#38

Post by uniqueuid »

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

This is one of the most laughably ignorant posts I've ever seen on the internet. > 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 Btrfs is the most actively developed filesystem in the kernel, both by LOC changed and the number of contributors. Facebook publicly stated that they run BTRFS on every webser…

Please correct me if I'm wrong, but the "1GB ram per TB" is for the de-duplication table.

ZFS' memory cache (ARC) by default uses up to 50% of system ram and frees this under pressure. You can also set it lower.

Re: Examining Btrfs

#39

Post by derbOac »

Can someone recommend a good overview of modern filesystems that covers performance and licensing issues? I liked this article but was left with the question "so what else do you use?"

It's been awhile (too long really) since I really tried to read up on this area. Last time I did I concluded that it was sort of a mess but lots of things were still in progress.

Re: Examining Btrfs

#40

Post by mavhc »

uniqueuid wrote: post #34
WastingMyTime89 wrote: post #28

Earlier quoted context omitted.

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

You're teasing, of course, but it shows the real problems. To take you up on that with a dangerous example that reinforces the point: To add a disk to an array whose used space is less than the capacity of a single disk, you can (DON'T DO THIS, IT'S DANGEROUS) (1) remove a disk from the array (it's degraded now) (2) reformat the single disk, put all data on there (3) create a sparse file with the size of one disk (4)…

How do you do it on another FS?
Post reply on HN