4 ms·
I wonder why that's the case? is it not well-maintained?
by akulbe 9y ago
I wonder why that's the case? is it not well-maintained?
- lima 9y agoRunning btrfs in production is still a nightmare in 2017. At least the random kernel crashes stopped. With proper care and feeding, it won't run out of metadata either but you need to monitor it closely and run nightly balances. Which probably kill your SSD. Documentation sucks. Get used to monitor the btrfs IRC channel closely and deduce what to do and what not to do on which kernel version. It works well for very particular use cases (file server with few random writes and much duplicate data). Cannot recommend it otherwise. Even Docker runs more stable on XFS.
- rodgerd 9y agoHave a look at the RAID 1 implementation. If you have a 2-disk mirror and one disk fails, you can mount the remaining disk one more time to try to recover. If you try and mount it a second time it is marked permanently read-only and can never be recovered. You need to dump the data and rebuild from scratch. It's 2017. It's been in development for almost a decade, and getting the simplest RAID case correct hasn't worked.
- cestith 9y agoRAID 5 and 6 were found to be losing data without a drive going bad. I pulled all my data off to backup and restored it on a freshly built array under XFS. That's not something I enjoy doing too often.
- rodgerd 9y agoYeah, having scrubs corrupt good data is basically the worst-case scenario for an FS whose selling point is checksumming for data integrity. I ran btrfs for several years, and while the features are great (per-subvolume RAID policies, lightweight snapshots, unRAID-style RAID), I got sick of testing my backups regularly. I wouldn't be surprised if that's not uncommon.