On Thu, Oct 26, 2017 at 4:34 AM, Zak Kohler <y...@y2kbugger.com> wrote:
> I will gladly repeat this process, but I am very concerned why this > corruption happened in the first place. Right. So everyone who can, needs to run the three scrubs on all available Btrfs volumes/devices and see if they get any discrepancies. I only ever use the online scrub so I have no idea if --offline or the older check --check-data-csum differ from it. scrub start scrub start --offline btrfs check --check-data-csum I think you've hit a software bug if those three methods don't exactly agree with each other. And it's a question which one is correct, or if they all have different bugs in them? > > More tests: > > scrub start --offline > All devices had errors in differing amounts > I will verify that these counts are repeatable. > Csum error: 150 > Csum error: 238 > Csum error: 175 > > btrfs check > found 2179745955840 bytes used, no error found > > btrfs check --check-data-csum > mirror 0 bytenr 13348855808 csum 2387937020 expected csum 562782116 > mirror 0 bytenr 23398821888 csum 3602081170 expected csum 1963854755 Offhand that sounds like three different results, which is sorta fakaked. > ... > > The only thing I could think of is that the btrfs version that I used to mkfs > was not up to date. Is there a way to determine which version was used to > create the filesystem? That information isn't in the superblock. I think it could be added to the device tree as a PERSISTENT_ITEM, although I'm not sure how useful it is. Anyway, I don't think it's related. mkfs.btrfs writes a tiny amount to the drive, and almost certainly the problem is happening later. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
