5 ms·
Which is kind of the point. BTRFS only has issues with RAID5/6 configurations. Using it as a filesystem for a single disk or partition should be totally fine.
by wolletd 3y ago
Which is kind of the point. BTRFS only has issues with RAID5/6 configurations. Using it as a filesystem for a single disk or partition should be totally fine.
- Dalewyn 3y agoEverything I've read about btrfs's RAID5/6 deficiencies is that it can't tolerate sudden losses of power (aka write hole problem), which I think is fine so long as you are aware of it and implement appropriate safety measures such as a UPS or APU. And besides, if you are doing RAID you are probably concerned with the system's uptime which probably means you will have implemented such measures anyway. Note that, yes, I'm aware most home users either aren't aware (nobody RTFM) or are too lazy/cheap to buy a UPS from Office Depot. So perhaps btrfs is warning people to save them from themselves.
- dark-star 3y agoA UPS will not much improve the reliability against sudden power loss. At least here in Europe it is much more likely that a PSU or other component fails than that the power line is suddenly interrupted. And lost writes are a problem that all filesystems have. I recommend reading the paper "Parity Lost and Parity Regained" by Krioukov at USENIX 08...
- amaccuish 3y agoKernel panic too...
- Mister_Snuggles 3y agoAnecdotally, this is untrue. Personally, BTRFS is the only filesystem that has ever caused me any data loss or downtime. I was using a single disk, so it should have been the perfect path. At some point the filesystem got into a state where the system would hang when mounting it read/write. I was able to boot off of a USB stick and recover my files, but I was unable to get the filesystem back into a state where it could be mounted read/write. At work, we used to run BTRFS on our VMs as that was the default. Without fail, every VM would eventually get into a state where a regular maintenance process would completely hang the system and prevent it from doing whatever task it was supposed to be doing. Systems that wrote more to their BTRFS filesystems experienced this sooner than ones that didn't write very much, but eventually every VM succumbed to this. Eventually the server team had to rebuild every VM using ext4. I know that anecdotes aren't data, but my experience with BTRFS will keep me from using it for anything even remotely important.
- grumpyprole 3y agoUnfortunately you got what you payed for! :) No one in the Linux world appears to be seriously investing in engineering a robust and reliable filesystem, with e.g. correctness proofs. We have only hobby projects.
- Mister_Snuggles 3y agoAt work, this all happened on a commercial Linux distribution which we do pay for. As far as I recall, their support was unable to resolve the issue, hence rebuilding all those VMs. I’m not on the server team, so I don’t know many details, but I was affected by this issue and it caused a lot of grief across the organization. So no, I don’t think we got what we paid for.
- grumpyprole 3y agoAre you sure brtfs is supported in production by your commercial Linux distribution? I would be surprised if this is true. RedHat and Ubuntu do not support it.
- Mister_Snuggles 3y agoIt was at the time, it may not be now.
- yjftsjthsd-h 3y agoFacebook literally uses it in production. There are plenty of insults we can use, but hobby project is not one of them.
- Mister_Snuggles 3y agoI honestly find it weird when I hear about companies like Facebook and Synology using it. Facebook could easily work around failures, they've surely got every part of their infrastructure easily replaceable, and probably automated at some level. I'm sure they wouldn't tolerate excessive filesystem failures, but they definitely have the ability to deal with some level of it. But Synology deploys thousands of devices to a wide variety of consumers in a wide variety of environments. What's their secret sauce to make BTRFS reliable that my work's commercial Linux distribution doesn't have? Surely there's more to it than just running it on top of md. Maybe in the years since I was burned by it things have greatly improved. Once bitten, twice shy though - I don't want to lose my data, so I'm going to stick to things that haven't caused me data loss.