On Mon, Dec 28, 2015 at 7:46 PM, Chris Murphy <[email protected]> wrote: > On Mon, Dec 28, 2015 at 7:28 PM, Duncan <[email protected]> wrote: >> Chris Murphy posted on Mon, 28 Dec 2015 17:10:14 -0700 as excerpted: >> >>> Hi, >>> >>> I (intentionally) used wipefs -a on a device with a btrfs. As expected >>> btrfs check doesn't recognize the device as having a btrfs volume >>> anymore. >>> >>> Slightly surprising that it doesn't mention other intact supers are >>> found. >>> >>> Most surprising that options -s1 --repair doesn't fix it. >>> >>> I thought maybe it's intentional, only with explicitly bad magic, and >>> I'd get different results if it were zero'd. So I zero'd it and I get >>> the same results. s0 superblock isn't repaired with --repair. >>> >>> Bug? >>> >>> Of course I can fix it with echo+dd. >> >> Btrfs check's -s option simply lets you use a different superblock. I >> don't believe check is designed to actually fix superblocks, tho I guess >> with --repair it fixes certain bad fields in them. >> >> What you want to actually recover bad superblocks from good copies is >> btrfs rescue super-recover. > > Yep! I forgot about that. But it's still confusing that particular > repair is split out.
OK so the warning I get from rescue super-recover makes this make sense: [root@f23m ~]# btrfs rescue super-recover /dev/sdb Make sure this is a btrfs disk otherwise the tool will destroy other fs, Are you sure? [y/N]: n It looks like it's a rudimentary check for only btrfs superblocks and isn't checking if the fs could plausibly be some other file system, which is admittedly quite a burden for any tool to have to do. -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
