On Sun, Mar 28, 2021 at 11:47 AM Richard Shaw <hobbes1069@xxxxxxxxx> wrote: > > I appreciate all the detailed response, but at the same time the answers seem often bi-polar... You can do all these great things with BTRFS! But even if you test your raid array multiple times, a bad firmware may still eat all your data :) It's uncommon even in the single device case. It takes a combination: a crash or power failure happening at the same time the firmware does something wrong. If you add raid1 to the mix, it's even less common all problems happen at the same time to two drives, in particular if the two drives don't share firmware bugs. But if there is a problem, there's a decent (not certain) chance of recovery by doing: mount -o rescue=usebackuproot There are three backup roots. If one is good, mount succeeds and nothing more need be done. But you might lose up to a couple of minutes of writes. Basically Btrfs does a rollback to a known good root and drops all the bad ones. Is this eating your data? Yes, as much as 2 minutes worth. If that doesn't work, what comes next depends on the kernel messages shown when the mount fails. And that unfortunately takes familiarity with Btrfs mount failure messages. My advice if anyone runs into a problem is to report a complete dmesg, and btrfs check --readonly. And in the meantime they can try: mount -o rescue=all That is a read-only mount that can skip over many kinds of significant root tree damage, and you can still get your data out using normal tools like rsync, cp, or any other backup program. And freshen up the backups just in case the problem can't be fixed. If that doesn't work there's 'btrfs restore' which is an offline scrape utility. Ugly, but again data not eaten. > I know you can't give absolute answers sometimes, but it feels like you're often a btrfs cheerleader and critic at the same time :) Yes. > It sounds like there needs to be an easy to find list of known good and known bad drives to use (be it btrfs or other similar filesystem). Yes but that takes a lot of data and work to find the trends and then publish it and maintain it. -- Chris Murphy _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
