On 8/2/16 1:51 PM, Jeff Mahoney wrote: > On 8/2/16 11:00 AM, Eric Sandeen wrote: ... >> I could imagine that maybe for each candidate super we find, we should >> look at its geometry, and spot-check the other locations that it indicates >> should contain a superblock. If we get enough semi-valid but conflicting >> "sets," maybe we should bail out and ask. It's quite a corner case, tho. > > I'm not sure a geometry check would've helped here. The superblock > geometry still would've covered the whole, unpartitioned device. Since > we're already linking with blkid, maybe a check to see if there's a > partition table on the device and bail if it sees one, unless forced? > The part that I'm still trying to explain is how it managed to get a > good magic from the log and then got the wrong uuid. Hm, yeah, maybe right off the bat, if the primary super looks bad do a blkid check, and a (sigh) "are you sure?" just like we do for mkfs. >> Any chance you have full xfs_repair output? > > Sure, below. I heard back from the reporter and confirmed that my > hypothesis of mkfs -> fdisk -> mkfs was what happened. He's on SLE12 > SP1, so that means xfsprogs 3.2.1. > > -Jeff > > --- > > labadmin:/ssd # xfs_repair postgre.raw -L > Phase 1 - find and verify superblock... > - reporting progress in intervals of 15 minutes > sb root inode value 18446744073709551615 (NULLFSINO) inconsistent with > calculated value 128 > resetting superblock root inode pointer to 128 > sb realtime bitmap inode 18446744073709551615 (NULLFSINO) inconsistent > with calculated value 129 > resetting superblock realtime bitmap ino pointer to 129 > sb realtime summary inode 18446744073709551615 (NULLFSINO) inconsistent > with calculated value 130 > resetting superblock realtime summary ino pointer to 130 huh. Ok, so I guess the primary in block zero was mostly-ok, and all of the backup supers were still more or less intact, and it didn't have to go searching... -Eric
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
