I too have lost an entire btrfs volume (single disk) because of a bad sector. It seems btrfs is very sensitive to bad sectors in metadata, compared to ext4.
Since then, I've formatted my btrfs partition to do RAID1 on metadata and haven't had problems since.
$ sudo btrfs fi df /
Data, single
System, DUP
Metadata, DUPPerhaps this is the secret - and should be made the default.
I don't use raid, precisely because I'm worried that failures will take down the entire set, and all of it will be unrecoverable.
I'm not at all suggesting that BTRFS is "buggy" unreliable, just, as you say, with certain kinds of disk errors (possibly rare, but it got me), the entire volume becomes unreadable, whereas I've always been able to recover files from extX or xfs volumes.
Perhaps it's just my bad luck though.
The default for single devices is to have DUP metadata, and for raid1 devices the default is raid1 metadata. These are the defaults, somehow they got bypassed. I think you're right that you need to think a little more and know a little more about btrfs to use it properly, but I hope that will change in the future.
From the article:
'And against the demand of some partners, we are still refusing to support “Automatic Defragmentation”, “In-band Deduplication” and higher RAID levels, because the quality of these options is not where it ought to be.'
I've only used btrfs on single disk systems.
Re:A straight talk about btrfs
by Dylan16807 on Thursday August 24, 2017 @08:53AM
(#15089667)
Isn't that the default?
"A single device filesystem will default [metadata] to DUP, unless a SSD is detected. Then it will default to single." https://btrfs.wiki.kernel.org/index.php/Manpage/mkfs.btrfs#O...
It's a relatively new feature (Jan-2016) and it's disabled by default for SSD devices (increased wear). Personally I prefer increased wear over unmountable volumes.
I am continuously amazed at the amount of people who have issues with btrfs. It's been absolutely rock solid over the time I've used it and I have 0 complaints (apart from the ext4 -> btrfs converter producing a corrupted btrfs filesystem, but the actual kernel btrfs code itself has been flawless).