On Nov 8, 2013, at 1:13 AM, Hugo Mills <hugo@xxxxxxxxxxxxx> wrote: > On Thu, Nov 07, 2013 at 10:56:10PM -0700, Chris Murphy wrote: >> What's the kernel and btrfs progs version? >> >> I wish the dmesg errors were more explicit about the nature of checksum errors: do the two metadata checksums mismatch each other (one of them matches with data), or the metadata checksums match each other but mismatch with data? > > If there's two copies, and one fails the checksum and the other > passes, then there will be a note following the failure that it > read the other checksum and succeeded, and repaired the problem. OK I guess that's fairly explicit. And a more explicit message that data is corrupt in the current case, is maybe the wrong thing to do because all we know is data checksum doesn't match what's stored in metadata. We don't actually know the significance of the data corruption. A bigger problem that was brought up a while ago is if we still have a way to read data that fails checksum, so we can attempt application level reconstruction. I'm also not seeing in the original report, any kernel messages that show what files (by path) have been affected which also makes understanding of the error messages less than clear. 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
