Hacker News new | ask | show | jobs
by jbronn 3026 days ago
From operations experience, the risks of data loss with btrfs far outweigh volume shrinking capabilities on either XFS or ZFS.
3 comments

I really would like more data about it. My impression is that the biggest limitation that btrfs suffers nowadays is a severely lacking communication. Even the official wiki is not so up to date, and there are a lot of horror stories surviving from years ago.

The situation has been quite reliable for some time now (single disk, raid{0,1,10}), moreover the feature set of btrfs is really wide (on par with zfs), with a very high flexibility: you can mix and match disks of different capacities, shrink and expand pools, change their redundance level through filtering, everything can be done online...

Even it it doesn't break your filesystem anymore: Performance is subpar in all aspects except sequential read/write even compared to ZFS. high snapshot count degrades performance and lot's of gotchas you discover after using it for a while. RAID1 is not RAID1 - it's oddness of the pid decides which disk to read from... scrub impacts io massivly. Tooling and documentation is not exactly great... lot's of quirky hacks to make up for design errors IMHO.

If it works for you, fine. Also it appears to get better - I won't touch it anymore if I can avoid it.

Fortunately, btrfs is really good at backups.

Well, so is ZFS, but in some situations, like choosing what filesystem to use on a rented dedicated server, any choice that could lead to a situation requiring physical hardware configuration changes is a non-starter.

ZFS licensing is an issue too, as it means that you can't just boot into any ol' Linux live CD (or remotely boot into a rescue environment) to fix the system or salvage the data on it.

> ZFS licensing is an issue too, as it means that you can't just boot into any ol' Linux live CD (or remotely boot into a rescue environment) to fix the system or salvage the data on it.

Sure you can. I've done just this with 3 different live CDs: ArchLinux, FreeBSD and OpenSolaris. I'm fairly sure I've also used ZFS on the Ubuntu Desktop live CD as well but that was just for playing rather than rescusing a degraded system.

FreeBSD and OpenSolaris probably aren't very useful, when trying to rescue a Linux system. Especially if you need to chroot and run things from there. (My need so far was to rescue non-booting system, because the zfs package upgrade went wrong and didn't update spl too. Re-running dracut would be a somewhat problematic from these two systems).

Ubuntu desktop live CD doesn't contain zfs, you have to install it from apt.

However, if you have a ZFS system, I see no problem with having an USB stick with minimal installation of your distro of choice, together with ZFS support. I'm glad I did have it since the ZFS install.

I think you're nitpicking a little to be honest. None of those problems are hard to workaround:

> FreeBSD and OpenSolaris probably aren't very useful, when trying to rescue a Linux system. Especially if you need to chroot and run things from there. (My need so far was to rescue non-booting system, because the zfs package upgrade went wrong and didn't update spl too. Re-running dracut would be a somewhat problematic from these two systems).

I do see your point but it really depends on the problem as not all recoveries require chroot / package management access. I've rescued Solaris (not OpenSolaris) with an OpenSuse live CD back when a cavalier opp chmodded /etc. I've rescued OpenSolaris with a FreeBSD CD back when a faulty RAID controller borked the file system. As for ArchLinux ISOs, I've used them to rescue more systems than I can count. But as you said, some problems do just require booting an instances of the host OS via some means.

> Ubuntu desktop live CD doesn't contain zfs, you have to install it from apt.

It took me all of about 10 minutes to bake the ZFS driver into the ISO. It's not hard compared to the other technical challenges you've discussed. Though if that's too much effort then I think you can also just apt it from the Live CD and manually modprobe it into the running kernel.

> However, if you have a ZFS system, I see no problem with having an USB stick with minimal installation of your distro of choice, together with ZFS support. I'm glad I did have it since the ZFS install.

Indeed. My preferred method is having rescue disks available over PXE booting. Before then I was forever hunting down my recovery disks or spare USB keys / CD-Rs. Not to mention the pain involved if the system I was trying to recover was my main workstation (ie the hardware I'd normally use to download and burn CDs on).

> None of those problems are hard to workaround:

Sure, there are very few problems that cannot be solved by throwing some time and sweat on them. However, when I do need to solve something, I prefer to not be sidetracked by sub-problems. Smooth sailing and all that.

It's much simpler to pull an usb key from the drawer or PXE boot, as you mentioned, and go on on solving the damaged system, than to start downloading and preparing a live distro somewhere.

Again, you're overstating things. If it genuinely takes you more than a couple of minutes to run apt and modprobe then I really think you shouldn't be allowed anywere near a degraded system to begin with. These aren't "sub-problems" - they're the absolute basics of system administration.
> Fortunately, btrfs is really good at backups.

For backing up to another file system? How so? Is there something like "zfs send" or even "xfsdump"?

Honest question - I haven't look that closely at btrfs.

Yes, "btrfs send" and "receive" exist for that purpose.
Mind that it doesn't work quite so well as ZFS: btrfs send/receive doesn't produce an identical file system as the source. ctimes aren't preserved, some attributes, and depending on mount options, ACLs and xattrs can vanish too.
Is there really any reason to believe that Btrfs has more risk of data loss than XFS or ZFS, at least on simple single or mirrored drives?

Honest question - my home box runs a Btrfs mirror on openSUSE.

The two most obvious reasons to assume so are that btrfs is in comparison relatively new and quite complex. Not to say zfs isn't complex, but I'd rather trust zfs just because of its age.

That being said, unless I really need those specific features, I go for ext4 whenever possible, as it has to be the most battle tested one, at least when it comes to *nix. It also seems that fsck.ext4 has almost magical powers sometimes, but that shouldn't stop you from making backups obviously.

Related: http://events.linuxfoundation.org/sites/events/files/slides/...