Old bugs in xfsprogs?

[Eric Sandeen]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 881 bytes
Desc: OpenPGP digital signature
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20160802/f3732221/attachment.sig>