6 ms·

I've just lost about a week of my life fighting with a bog-simple device replace on a RAID1 btrfs filesystem. I had the misfortune of receiving a replacement di

I've just lost about a week of my life fighting with a bog-simple device replace on a RAID1 btrfs filesystem. I had the misfortune of receiving a replacement disk which was also bad, and somehow the process of attempting to rebuild the array hosed the filesystem on the good disk. Asked for help on the irc channel and the only advice I got was "upgrade to the latest btrfs-tools" (because apparently the "stable" version shipped with debian stable isn't really stable when a problem arises?). I also was misled by btrfs-check which happily scanned my un-mountable filesystem with no complaints, and learned on the irc that btrfs-check is "an odd duck," in that it doesn't actually check all the things the documentation says it does. This experience, and the fact that simple things like the "can only mount a degraded filesystem rw one time" bug remain after years of complaints, simply because the devs adopt an arrogant "you're doing it wrong if you don't fix your filesystem the first time you mount it" (despite the tools giving you no indication that's required) attitude, have convinced me to never touch btrfs again. So keep parroting "it's stable!" all you want, my experience has shown btrfs is "stable" until you have a problem.

roblabla 5y ago
> (because apparently the "stable" version shipped with debian stable isn't really stable when a problem arises?). "Stable" here means "unchanging". It doesn't mean bug-free. My personal experience is, you'll generally encounter less bugs on a rolling release distro (like arch) or distros with frequent updates (like fedora). The upside of stable distros (like debian) is that new bugs (or other breaking changes) won't be introduced during the distro's release lifetime.
- Already__Taken 5y ago
  I wasted far too much of my life fixing stuff that already has fixes released 6 years ago because "oh we should use 'stable'"
stryan 5y ago
Debian's actually one of the distros I thought of when I said "properly set up". Their tools packages are very out of date, they don't install the proper maintenance setup by default, and the installer doesn't support subvolumes. Going through the man page, yeah I see it does mention using btrfs-check for various parts when generally that is not recommended (see the Arch Wiki[0] or OpenSUSE docs[1] to see how they warn against it). > So keep parroting "it's stable!" all you want, my experience has shown btrfs is "stable" until you have a problem. I've been running it on multiple production machines for years now, as well as my home machine. Facebook has been using it in production for I think over a decade now, and it's used by Google and Synology on some of their products. I'm not saying it doesn't have problems (I've certainly faced a few), but it is tiresome reading the same cracks against it because they set it up without reading the docs. You never see the same thing against someone running ZFS without regular scrubs or in RAIDZ1. [0]https://wiki.archlinux.org/title/Btrfs#btrfs_check https://wiki.archlinux.org/title/Btrfs#btrfs_check [1]https://en.opensuse.org/SDB:BTRFS https://en.opensuse.org/SDB:BTRFS
- petschge 5y ago
  Thing is: I like filesystems that don't eat my data when I don't spend a day or two reading the documentation before I use them.
  - stryan 5y ago
    btrfs is default on two distros (that I know of) OpenSUSE and Fedora. If you're using one of those two distros, don't read the documentation, and then your data is eaten/etc then that's fair and you can rightfully be upset. I would be too. But if you're using it in some other setup, then that means you went out of your way to try a more complicated filesystem. I would think it's reasonable to do at least a quick scan of the btrfs wiki or your distro's documentation before continuing with that, the same way I'd expect someone would do the same for ZFS.
    - wolrah 5y ago
      > I would think it's reasonable to do at least a quick scan of the btrfs wiki or your distro's documentation before continuing with that, the same way I'd expect someone would do the same for ZFS. I would argue that the defaults should not be dangerous. If a filesystem is released in to the world as stable and ready for use, it's not absurd to expect that running mkfs.<whatever> /dev/<disk> will get you something that's not going to eat your data. It might not be optimized, but it shouldn't be dangerous. Dangerous defaults are loaded footguns and should be treated as bugs. If there is no safe option, there should not be a default and the user should be required to explicitly make a choice. At that point you can blame them for not reading the documentation.
      - wtallis 5y ago
        What dangerous defaults do you think may exist with btrfs? A simple mkfs.btrfs won't set you up for later trouble unless you go out of your way to give it multiple devices and ask for one of the parity RAID modes. There are some arguable footguns in the btrfs-tools workflows for repairing a damaged filesystem, but that's exactly the fragile situation where asking the user to RTFM before making more changes is perfectly reasonable.

roblabla 5y ago

> (because apparently the "stable" version shipped with debian stable isn't really stable when a problem arises?). "Stable" here means "unchanging". It doesn't mean bug-free. My personal experience is, you'll generally encounter less bugs on a rolling release distro (like arch) or distros with frequent updates (like fedora). The upside of stable distros (like debian) is that new bugs (or other breaking changes) won't be introduced during the distro's release lifetime.

Already__Taken 5y ago
I wasted far too much of my life fixing stuff that already has fixes released 6 years ago because "oh we should use 'stable'"

stryan 5y ago

Debian's actually one of the distros I thought of when I said "properly set up". Their tools packages are very out of date, they don't install the proper maintenance setup by default, and the installer doesn't support subvolumes. Going through the man page, yeah I see it does mention using btrfs-check for various parts when generally that is not recommended (see the Arch Wiki[0] or OpenSUSE docs[1] to see how they warn against it). > So keep parroting "it's stable!" all you want, my experience has shown btrfs is "stable" until you have a problem. I've been running it on multiple production machines for years now, as well as my home machine. Facebook has been using it in production for I think over a decade now, and it's used by Google and Synology on some of their products. I'm not saying it doesn't have problems (I've certainly faced a few), but it is tiresome reading the same cracks against it because they set it up without reading the docs. You never see the same thing against someone running ZFS without regular scrubs or in RAIDZ1. [0]https://wiki.archlinux.org/title/Btrfs#btrfs_check https://wiki.archlinux.org/title/Btrfs#btrfs_check [1]https://en.opensuse.org/SDB:BTRFS https://en.opensuse.org/SDB:BTRFS

petschge 5y ago
Thing is: I like filesystems that don't eat my data when I don't spend a day or two reading the documentation before I use them.
- stryan 5y ago
  btrfs is default on two distros (that I know of) OpenSUSE and Fedora. If you're using one of those two distros, don't read the documentation, and then your data is eaten/etc then that's fair and you can rightfully be upset. I would be too. But if you're using it in some other setup, then that means you went out of your way to try a more complicated filesystem. I would think it's reasonable to do at least a quick scan of the btrfs wiki or your distro's documentation before continuing with that, the same way I'd expect someone would do the same for ZFS.
  - wolrah 5y ago
    > I would think it's reasonable to do at least a quick scan of the btrfs wiki or your distro's documentation before continuing with that, the same way I'd expect someone would do the same for ZFS. I would argue that the defaults should not be dangerous. If a filesystem is released in to the world as stable and ready for use, it's not absurd to expect that running mkfs.<whatever> /dev/<disk> will get you something that's not going to eat your data. It might not be optimized, but it shouldn't be dangerous. Dangerous defaults are loaded footguns and should be treated as bugs. If there is no safe option, there should not be a default and the user should be required to explicitly make a choice. At that point you can blame them for not reading the documentation.
    - wtallis 5y ago
      What dangerous defaults do you think may exist with btrfs? A simple mkfs.btrfs won't set you up for later trouble unless you go out of your way to give it multiple devices and ask for one of the parity RAID modes. There are some arguable footguns in the btrfs-tools workflows for repairing a damaged filesystem, but that's exactly the fragile situation where asking the user to RTFM before making more changes is perfectly reasonable.