Am Mon, 21 Dec 2015 10:23:31 +0800 schrieb Qu Wenruo <quwen...@cn.fujitsu.com>:
> > > Chris Murphy wrote on 2015/12/20 19:12 -0700: > > On Sun, Dec 20, 2015 at 6:43 PM, Qu Wenruo > > <quwen...@cn.fujitsu.com> wrote: > >> > >> > >> Chris Murphy wrote on 2015/12/20 15:31 -0700: > > > >>> I think the cause is related to bus power with buggy USB 3 LPM > >>> firmware (these enclosures are cheap maybe $6). I've found some > >>> threads about this being a problem, but it's not expected to > >>> cause any corruptions. So, the fact Btrfs picks up one some > >>> problems might prove that (somewhat) incorrect. > >> > >> > >> Seems possible. Maybe some metadata just failed to reach disk. > >> BTW, did I asked for a btrfs-show-super output? > > > > Nope. I will attach to this email below for both devices. > > > >> If that's the case, superblock on device 2 maybe older than > >> superblock on device 1. > > > > Yes, looks iike devid 1 transid 4924, and devid 2 transid 4923. And > > it's devid 2 that had device reset and write errors when it vanished > > and reappeared as a different block device. > > > > Now all the problem is explained. > > You should be good to mount it rw, as RAID1 will handle all the > problem. How should RAID1 handle this if both copies have valid checksums (as I would assume here unless shown otherwise)? This is an even bigger problem with block based RAID1 which does not have checksums at all. Luckily, btrfs works different here. > Then you can either use scrub on dev2 to fix all the > generation mismatch. I better understand why this could fix a problem... > Although I prefer to wipe dev2 and mount dev1 as degraded, and > replace the missing dev2 with a good device/usb port. Given the assumption above I'd do that, too (but check if the "original" has no block errors before discarding the mirror). -- Regards, Kai Replies to list-only preferred. -- 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