5 ms·

From operations experience, the risks of data loss with btrfs far outweigh volume shrinking capabilities on either XFS or ZFS.

by jbronn 9y ago

CyberShadow 9y ago
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.
- deleted 9y ago
  [deleted]
- e12e 9y ago
  > 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.
  - Vogtinator 9y ago
    Yes, "btrfs send" and "receive" exist for that purpose.
    - chungy 9y ago
      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.
- laumars 9y ago
  > 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.
  - vetinari 9y ago
    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.
    - laumars 9y ago
      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).
muxator 9y ago
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...
- nisa 9y ago
  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.
DCKing 9y ago
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.
- iforgotpassword 9y ago
  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/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf http://events.linuxfoundation.org/sites/events/files/slides/...

From operations experience, the risks of data loss with btrfs far outweigh volume shrinking capabilities on either XFS or ZFS.

by jbronn 9y ago

From operations experience, the risks of data loss with btrfs far outweigh volume shrinking capabilities on either XFS or ZFS.

CyberShadow 9y ago

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.

deleted 9y ago
[deleted]
e12e 9y ago
> 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.
- Vogtinator 9y ago
  Yes, "btrfs send" and "receive" exist for that purpose.
  - chungy 9y ago
    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.
laumars 9y ago
> 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.
- vetinari 9y ago
  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.
  - laumars 9y ago
    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).

muxator 9y ago

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

nisa 9y ago
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.

DCKing 9y ago

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.

iforgotpassword 9y ago
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/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf http://events.linuxfoundation.org/sites/events/files/slides/...