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

81–90 of 112 posts

Re: Examining Btrfs

#81

Post by ajross »

curt15 wrote: post #64
ajross wrote: post #14

Earlier quoted context omitted.

ZFS is a more mature and (maybe?) more performant solution to... the same wrong problem. The modern world doesn't want this stuff from its filesystems. It just doesn't. Modern flash devices are extremely reliably and outrageously fast, and they pervasively sit on high bandwidth internet connections which provide reliable backup for virtually every application imaginable. RAID and checksumming[1] just isn't used at th…

Isn't Lustre designed specifically for ZFS as its backing filesystem?

No, Lustre shipped on ext4 for years and years. Not an expert, but IIRC there aren't any core/major/whatever features in ZFS being leveraged in an irreplaceable way.

Again, ZFS works fine, it's there (so is btrfs). Use it if it does something you like. It's just not really "worth" the level of complexity involved, and the window has long since closed for fancy filesystems to change any major paradigms of computation. This is dinosaur technology, basically.

Re: Examining Btrfs

#83

Post by tashbarg »

morning_gelato wrote: post #80
mst wrote: post #77

Earlier quoted context omitted.

I would argue that the 'degraded' stuff is a valid but different critique - and in fact is covered in a completely separate part of the article at some length.

I think we are in agreement. I was responding to the comment that stated "BTRFS delivers „classic“ RAID1 and more/better.", which is what I am disagreeing with. Requiring that mount options be changed whenever there is a drive failure (despite having sufficient redundancy) is definitely an anti-feature in my book.

There’s no need for changing mount options. If you want to allow mounting of degraded arrays, just put the degraded option there from the start.

Re: Examining Btrfs

#84

Post by nybble41 »

tw04 wrote: post #50
COGlory wrote: post #36

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

>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. That's simply not true. I can do a RAID-1 (mirror) with 3 drives on ZFS or mdadm and lose 2 drives. I can do it with 10 drives and lose 9. https://www.thegeekdiary.com/how-to-add-a-3rd-disk-to-create... >There are many use cases for RAID-0, but the author is actin…

> I can do a RAID-1 (mirror) with 3 drives on ZFS or mdadm and lose 2 drives.

You can do this with BTRFS also; it's called RAID1C3 (for three copies). RAID1C4 is also an option with larger arrays.

The issue is that if you have, say, four drives and standard RAID-1 (two copies) it doesn't divide the drives into mirrored pairs where you could lose one drive from each pair without any ill effect (like RAID-10), but rather just ensures that each piece of data is stored on any two different drives. With 4-drive RAID-10 if you lose two drives you have a 50% chance of losing the whole array, since both failing drives could be from the same pair. With BTRFS RAID1 in a four-drive array you have a high probability of losing both copies of some of the data no matter which two drives fail.

RAID-6 is strictly better than either, though, since you can lose any two drives and still access all your data.

Re: Examining Btrfs

#85

Post by flas9sd »

I understand the audience of the ars article is people running larger setups with redundant disk arrays, managing lots of data reliably.

But when it comes to what you use in a laptop or desktop, with maybe one more slot for a ssd/nvme or an external disk, btrfs snapshots with incremental send+receive to the second disk or over the network is a good argument in favor of giving it a try.

Re: Examining Btrfs

#86

Post by mst »

tashbarg wrote: post #83
morning_gelato wrote: post #80

Earlier quoted context omitted.

I think we are in agreement. I was responding to the comment that stated "BTRFS delivers „classic“ RAID1 and more/better.", which is what I am disagreeing with. Requiring that mount options be changed whenever there is a drive failure (despite having sufficient redundancy) is definitely an anti-feature in my book.

There’s no need for changing mount options. If you want to allow mounting of degraded arrays, just put the degraded option there from the start.

That sounds to me like it was originally set up that way early in development because they wanted people to give immediate manual attention to a system before booting it in that state.

If btrfs is mature enough that it's "safe" to boot missing a disk now I think either the defaults or the documentation probably want changing to make that clearer.

Like, I get "oh just add this option" as a response but in this case the fact distros don't default to adding it and the docs don't say "sure, do that" somewhere prominent mean I'm allowed to be a bit worried about how safe it actually is.

Re: Examining Btrfs

#87

Post by guenthert »

dosman33 wrote: post #72

Yet another knock-off of Lustre. Lustre is not perfect, and I'm not suggesting it has a place in the mainline kernel, but it sounds like neither does BTRFS. When you get to large scale (multi-petabyte) filesystems there are not many options, it's GPFS, Lustre, or roll your own. Lustre development has been indirectly sponsored by the DoE for a long time now. And if Lustre didn't exist IBM would charge even more for GP…

Uh, BTRFS and Lustre can't easily be compared. The former is exclusively a single-host fs, the latter is a cluster-only fs. The former focuses (more or less successfully) on data resilience and availability, the latter on performance.

There are quite a few large scale distributed file systems. XtreemFS, Hadoop and Ceph come to mind. There are others, e.g. OrangeFS (successor of PVFS), PanFS, etc. .

Re: Examining Btrfs

#88

Post by ok123456 »

jacknews wrote: post #18

The ONLY time I've actually lost data, was with BTRFS, and only using it as a basic single-volume filesystem, no RAID, snapshots, or anything complex. BTRFS does not seem to recover well from media errors. I've had plenty of those, and always been able to recover at least partial data (minus the bad media) with other FS's.

And the "rescue" commands tell you not to use them unless you've been blessed by someone on a mailing list, and that they can actually cause MORE damage.

I was using BTRFS on my workstation and all of a sudden some garbage got written to the extent-tree, and it was toast. Never using BTRFS again. I had backups and was able to recover 99.99%, but the recuse tools were garbage. I finally killed it after it had spent a month, from July 4 until August 4, doing apparently nothing. And this was this year. This was a normal desktop configuration, single drive. I wasn't using any of the real features of the FS other than COW.

Re: Examining Btrfs

#89

Post by jbotz »

jacknews wrote: post #18

The ONLY time I've actually lost data, was with BTRFS, and only using it as a basic single-volume filesystem, no RAID, snapshots, or anything complex. BTRFS does not seem to recover well from media errors. I've had plenty of those, and always been able to recover at least partial data (minus the bad media) with other FS's.

How long ago was this?

My experience about a year ago was the opposite, btrfs held up really well on a failing drive and I managed to copy the filesystem with 'btrfs send' without suffering any data loss or corruption as far as I've been able to tell. I also had a btrfs filesystem on an external drive with a lose USB plug that caused it to disconnect once in a while, and didn't have any corruptions or loss on that one either.

Re: Examining Btrfs

#90

Post by throwdbaaway »

ajross wrote: post #14
nikbackm wrote: post #3

Earlier quoted context omitted.

What about ZFS?

ZFS is a more mature and (maybe?) more performant solution to... the same wrong problem. The modern world doesn't want this stuff from its filesystems. It just doesn't. Modern flash devices are extremely reliably and outrageously fast, and they pervasively sit on high bandwidth internet connections which provide reliable backup for virtually every application imaginable. RAID and checksumming[1] just isn't used at th…

> ZFS/btrfs has nothing to offer someone working on an S3-like service, or a globalized database, either.

Why would that be the case? Let's say I want to setup a vitess cluster (planetscale = globalized database). I can easily delegate the compression logic to zfs, which works way better than innodb table compression or transparent page compression. I can rely on zfs atomic write to safely disable innodb doublewrite, which has been the number one bottleneck to scale writes until it was enhanced recently.

Post reply on HN