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
signature.asc
Description: OpenPGP digital signature
|