On Sep 4, 2014, at 6:20 PM, john terragon <jterragon@xxxxxxxxx> wrote: > Everyone knows what raid0 entails. Moreover, with btrfs being an > experimental fs, not having backups would obviously be pure idiocy. That is a bit of hyperbole. There is such a thing as innocently ignorant, as well as the misinformed. > I don't know if you are a btrfs developer but that "pretty serious" > was not meant to offend them nor to complain. I think the "pretty serious" statement is legit. No one wants filesystems themselves responsible for losing data, if they did this with any regularity we wouldn't trust them, and we need to trust them. Since there are myriad sources for data loss or corruption a good autopsy is needed to understand the problem, and then whether the fix is one of prevented or can also be done during normal read, scrub, or btrfsck. If the conditions can be repeated and reproduce the problem, that's a happy day. > So, the "pretty serious" was more due to the surprise than anything else. Right. Off chance scrub might fix the problem and then the evidence of why a regular read can't deal with it is gone. So I'd either take a btrfs-image first, or do a read-only non-background scrub and see what you get in dmesg: btrfs scrub start -BRr <mp> And btrfs check unmounted and without any options. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
