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

81–90 of 240 posts

Re: Five Years of Btrfs

#81

Post by nickik »

xzcat wrote: post #53
pmarreck wrote: post #24

Earlier quoted context omitted.

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

That's why FS integration into the kernel would have been so important for the whole software ecosystem.

Re: Five Years of Btrfs

#82

Post by KaiserPro »

StreamBright wrote: post #40
derefr wrote: post #27

A question for HN: what filesystem and/or block-device abstraction layer would you use on a database server, if you wanted to perform scheduled incremental backups using filesystem-level consistent snapshotting and differential snapshot shipping to object storage, instead of using the DBMS’s own replication layer to achieve this effect? (I.e. you want disaster recovery, not high availability.) Or, to put that another…

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

SAN and s3 are different beasts.

EBS is very much a SAN, if you read the docs, the Nitro HBA Controllers have dedicated bandwidth allocation for doing just EBS.

As there is a dedicated network for just servicing block storage, that sounds suspiciously like a Storage Area Network to me.

S3 for backup makes lots of sense, its ubiqutous, reliable and smeared over lots of regions. It also works well with large files. Its also orders of magnitude cheaper than EBS to run.

Re: Five Years of Btrfs

#83

Post by kstrauser »

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…

I think there's a selection bias here: people using RAID 5/6 may not be using ZFS as much because it's not well supported. I'd bet money that those levels are much more common in SOHO settings than RAID 10 is, because it's still the sweet spot for "I need lots of storage" vs "...and am willing to spend drive's worth of storage on availability". For instance, anyone using a NAS primarily as a backup target for desktops and small servers may love RAID 5, but be unwilling to throw money at a "better" RAID 10 setup.

Re: Five Years of Btrfs

#84

Post by Arnavion »

derefr wrote: post #30
Shalle135 wrote: post #25

Is there any specific reasons to run btrfs over for example ext4? You can create/shrink/grow pools, create encrypted volumes etc by using LVM. It all depends on the application but in the majority of cases the io performance of btrfs is worse than the alternatives. Redhat for example choose to deprecate btrfs for unknown reasons while SUSE made it it’s default. The future of it seems uncertain which may cause a lot o…

Redhat and SUSE (SLES) are both enterprise environments, so at every level, they have to choose one tech stack to go all-in on (i.e. to train their support staffs on), and then discourage their customers from using the others. (“Deprecating” a component, for such orgs, means that some of their customers are now stuck with it, and they’ll continue to support those customers in their use of it, but they certainly won’t…

The enterprise provider that actually develops btrfs continues to support btrfs, and one enterprise provider that doesn't stopped supporting it.

People treat RH stopping support of btrfs as some sort of death knell for it. Meanwhile all the btrfs users are confused why RH's opinion should matter at all when they weren't that involved with developing it in the first place.

As an opensuse user, btrfs has saved multiple machines from botched updates by letting me revert to the snapshot from right before the update was applied (opensuse's update tool automatically takes snapshots before and after updates).

Re: Five Years of Btrfs

#85

Post by bbatha »

yjftsjthsd-h wrote: post #79
clSTophEjUdRanu wrote: post #73

Earlier quoted context omitted.

I really don't understand the insane hype around ZFS. You can't read any thread that touches on filesystems without the ZFS zealots coming out.

ZFS is mature/stable, its feature set is basically unmatched (data checksums, compression, atomic snapshots, RAID(0,1,10,5,6), send/receive) by any other option on Linux, and what competition it does have is unstable in some configurations (BTRFS), essentially dead in the water (reiserfs), in early development (bcachefs), or far more complex to manage (gluster, ceph, LVM+XFS). Other than the licensing issue, ZFS is b…

Also don't underrate good documentation and easy to use tooling.

Re: Five Years of Btrfs

#86

Post by nickik »

jbotz wrote: post #20
ailideex wrote: post #5

Earlier quoted context omitted.

What about the reliability? Are many people losing data with Btrfs?

As best I can tell, reports of data loss on btrfs are all from the early 20-teens; after about 2014 or so I can't find anyone who claims to have lost data due to a btrfs bug on an up-to-date system.

That is just nonsense. Btrfs had well known and well published issues for years. And since when are the data of 20 somethings not important?

Re: Five Years of Btrfs

#87

Post by lostlogin »

xzcat wrote: post #53
pmarreck wrote: post #24

Earlier quoted context omitted.

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

> I only have a primary self-hosted one that's on an RPi in my networking cabinet, and the second entry is Google.

I was under the impression that there was no such thing as primary and secondary for DNS, just ‘here is one’ and ‘here is another’, with someone going for a terrible naming system of ‘primary’ and secondary’. I’m no expert and my knowledge come from messing about with Pihole and reading their documentation.

Re: Five Years of Btrfs

#88

Post by the8472 »

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…

btrfs has send/recv. And dedup, which is more efficient that ZFS' since it can be performed offline, on select parts of the filesystem and doesn't have to keep gigabytes of dedup tables in memory.

Re: Five Years of Btrfs

#89

Post by boring_twenties »

nickik wrote: post #86
jbotz wrote: post #20

Earlier quoted context omitted.

As best I can tell, reports of data loss on btrfs are all from the early 20-teens; after about 2014 or so I can't find anyone who claims to have lost data due to a btrfs bug on an up-to-date system.

That is just nonsense. Btrfs had well known and well published issues for years. And since when are the data of 20 somethings not important?

"Early 20-teens" means the years 2010-2014 or so in this case. Nothing to do with people or their age.

Re: Five Years of Btrfs

#90

Post by loudmax »

nickik wrote: post #65
loudmax wrote: post #38

Earlier quoted context omitted.

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

> 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 is simply totally false no matter how many times people repeat it. It pure FUD. Sun picked the licence because they had to allow linking with closed code for their products, going with the GPL was simply not viable given the situation with drivers on their platfor…

Sun's motivation for choosing the CDDL is beside the point. Unless ZFS is released under a license that allows it to be redistributed under the GPL, ZFS cannot be legally built into Linux as a filesystem.

If you have reason to believe that Linux developers can go ahead and simply integrate ZFS into Linux without worrying about the license, I'm sure lawyers from the FSF, IBM, Cannonical, etc would love to hear your explanation.

Post reply on HN