5 ms·
BTRFS has been stable for years now as long as you don't use unsupported features like the aforementioned RAID5. A properly set up btrfs system is fine for prod
by stryan 5y ago
BTRFS has been stable for years now as long as you don't use unsupported features like the aforementioned RAID5. A properly set up btrfs system is fine for production use, though note the "properly set up" bit, as a good number of distros still don't set it up right. I suspect the latter bit is why people continue to have issues with it (which is definitely a big downside compared to something like ZFS's "no admin intervention required" policy).
Regardless, in-place conversion is specifically a feature of btrfs due to how its designed. Since it doesn't require a lot of fixed metadata, you can convert a fs in-place by throwing the btrfs metadata into unallocated space and just point to the same blocks as the original fs. I think it even copies the original fs's metadata too, so you can mount the filesystem as either the original or btrfs for a while.
- LukeShu 5y agoWhat are distros doing to set it up wrong? (I've been a happy user of btrfs for several years now https://news.ycombinator.com/item?id=21446761 https://news.ycombinator.com/item?id=21446761)
- stryan 5y agoTo be clear, I'm not saying distros are setting it up "wrong" just not..correctly? As in, if I setup a filesystem I would assume most distros would set it up with best practices in mind. What I'm trying to convey is most of the time when I help someone out with btrfs issues it always turns out they haven't been running regular scrubs or balances and their distro didn't setup anything so they didn't know. Or they don't understand how much diskspace they have because their distro's docs still have them running du instead of "btrfs filesystem usage". For specific distros, arch/arch-derivatives had autodefrag as a default mount option which caused some thrashing a while back and IIRC Debian still doesn't support subvolumes properly, as well as not installing btrfs-maintenance.
- ghostly_s 5y agoI'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 agoI 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 agoDebian'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 agoThing 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.
- gigatexal 5y agoEvery other fs works without tweaks. Having to fiddle with a fs to get it just right means it’s not production grade. Who fiddles with ext4 or xfs after formatting it?
- sp332 5y ago> BTRFS has been stable for years now As far as I can tell, that is true. But given the number of years it spent broken, the amount of time I spent recovering broken arrays, and the (unknown but >0) number of my files that it ate, you'll forgive me for not being enthusiastic now.