RAID 5/6 is somewhat broken, and some people might consider the lack of built in encryption or support for a cache disk as problems. For some reason it seems popular to blame it for data loss.
That being said, it is my favorite file system and I never had problems with data loss, but I use ECC RAM on my desktop as is strongly recommended if you use btrfs or zfs (another potential downside).
The recommendation for ECC memory is simply because you can’t be totally sure stuff won’t go corrupt with only the safety measures of a checksummed CoW filesystem; if the data can silently go corrupt in memory the data could still go bad before getting written out to disk or while sitting in the read cache. I wouldn’t really say that’s a downside of those filesystems, rather it’s simply a requirement if you really care about preventing data corruption. Even without ECC memory they’re still far less susceptible to data loss than conventional filesystems.
I’ve been using BTRFS for years without issue, albeit with the standard c raid modes and not 5/6.
It saved my ass when a power supply issue popped up, causing my array’s hard drives to randomly drop out when reading/writing data. Managed to recover all data just fine, although it did take a while
I’ve been using btrfs for years, and I’d swear I’ve had fewer problems with it than ext4. I’ve never experienced any sort of data loss as a result of the fs.
I’m really interested to play with bcachefs; evolution and competition is a great thing, and it’d be nice to have a reliable RAID5 built in. While I normally prefer Unix-philosophy tooling, needing layers of different tools to get an FS working is an exception that has caused me trouble in the past, so I’m all for a batteries-included solution.
The proof in the pudding, for me, will be how easy or hard it is to administer. Messing with the fs tooling is something I do only rarely, so ease-of-use has a lot of value to me. This is why I don’t prefer ZFS; the btrfs tooling seems more intuitive.
Functionally it’s pretty solid (I use it everywhere, from portable drives to my NAS and have yet to have any breaking issues), but I’ve seen a number of complaints from devs over the years of how hopelessly convoluted and messy the code is.
Yeah, these days Btrfs is solid and well proven for many use-cases, but its old reputation will probably never go away, at least on reddit. Interestingly BcacheFS have a great reputation, despite not being in Linux , having a way to go yet and only having one single developer which is a big problem, I think Linus worries about that too.
If it lives up to everything Kent Overstreet says about it, it will be a great filesystem and I’ll be happy to use it, until then I’m doing good with Btrfs. On my PC I’ll probably never notice any difference between the two.
How is btrfs a mess?
RAID 5/6 is somewhat broken, and some people might consider the lack of built in encryption or support for a cache disk as problems. For some reason it seems popular to blame it for data loss.
That being said, it is my favorite file system and I never had problems with data loss, but I use ECC RAM on my desktop as is strongly recommended if you use btrfs or zfs (another potential downside).
The recommendation for ECC memory is simply because you can’t be totally sure stuff won’t go corrupt with only the safety measures of a checksummed CoW filesystem; if the data can silently go corrupt in memory the data could still go bad before getting written out to disk or while sitting in the read cache. I wouldn’t really say that’s a downside of those filesystems, rather it’s simply a requirement if you really care about preventing data corruption. Even without ECC memory they’re still far less susceptible to data loss than conventional filesystems.
I’ve been using BTRFS for years without issue, albeit with the standard c raid modes and not 5/6.
It saved my ass when a power supply issue popped up, causing my array’s hard drives to randomly drop out when reading/writing data. Managed to recover all data just fine, although it did take a while
I’ve been using btrfs for years, and I’d swear I’ve had fewer problems with it than ext4. I’ve never experienced any sort of data loss as a result of the fs.
I’m really interested to play with bcachefs; evolution and competition is a great thing, and it’d be nice to have a reliable RAID5 built in. While I normally prefer Unix-philosophy tooling, needing layers of different tools to get an FS working is an exception that has caused me trouble in the past, so I’m all for a batteries-included solution.
The proof in the pudding, for me, will be how easy or hard it is to administer. Messing with the fs tooling is something I do only rarely, so ease-of-use has a lot of value to me. This is why I don’t prefer ZFS; the btrfs tooling seems more intuitive.
Functionally it’s pretty solid (I use it everywhere, from portable drives to my NAS and have yet to have any breaking issues), but I’ve seen a number of complaints from devs over the years of how hopelessly convoluted and messy the code is.
I’ve yet to see someone state this outside of Reddit and I doubt those were devs.
Yeah, these days Btrfs is solid and well proven for many use-cases, but its old reputation will probably never go away, at least on reddit. Interestingly BcacheFS have a great reputation, despite not being in Linux , having a way to go yet and only having one single developer which is a big problem, I think Linus worries about that too.
If it lives up to everything Kent Overstreet says about it, it will be a great filesystem and I’ll be happy to use it, until then I’m doing good with Btrfs. On my PC I’ll probably never notice any difference between the two.