Hi Eric,
Nothing more interesting. From the log:
2016-04-04T14:48:48.735738-04:00 manitou kernel: [271211.548878] XFS (dm-24):
Mounting V4 Filesystem
2016-04-04T14:48:48.882738-04:00 manitou kernel: [271211.694242] XFS (dm-24):
Ending clean mount
Then no more logs about dm-24.
Also no errors from the underlying storage (verified in SANtricity) which is an
IS5000. The filesystem was new, the first mount was on 2016-04-04.
manitou:~ # blkid /dev/dm-24
/dev/dm-24: UUID="1da22ae2-a572-4db7-b177-b90021a20863" TYPE="xfs"
Thank you for your help,
StÃphane
-----Message d'origine-----
DeÂ: Eric Sandeen [mailto:sandeen@xxxxxxxxxxx]
EnvoyÃÂ: 20 avril 2016 16:14
ÃÂ: StÃphane Larose <Stephane.Larose@xxxxxxxxxxxxxx>
ObjetÂ: Re: xfs_repair couldn't verify primary superblock
On 4/20/16 1:50 PM, StÃphane Larose wrote:
> Hello,
>
>
>
> When I try to mount a cleany unmounted XFS filesystem, I get those errors in
> the log :
>
>
> [1650856.121229] XFS (dm-24): Mounting V4 Filesystem [1650856.135455]
> XFS (dm-24): Log inconsistent or not a log (last==0, first!=1)
> [1650856.135461] XFS (dm-24): empty log check failed [1650856.135463]
> XFS (dm-24): log mount/recovery failed: error 22 [1650856.135495] XFS
> (dm-24): log mount failed
You could maybe use xfs_logdump to see what's there, but...
> I have tried xfs_repair butâ
>
> manitou:~ # xfs_repair /dev/dm-24
>
> Phase 1 - find and verify superblock...
> couldn't verify primary superblock - not enough secondary superblocks with
> matching geometry !!!
>
> attempting to find secondary superblock...
> ........................................
> After a lot of dots, xfs_repair canât find secondary superblocks.
>
> This is where my knowledge of XFS filesystem stops. Looking at the superblock
> information, I have a feeling that the primary superblock is fine but not the
> secondary superblocks (strange blocksize and dblocks numbers). Is there any
> way to copy the primary superblock to the secondary superblocks? Maybe this
> is not a good idea?
>
> Thank you for any help!
>
... the stated locations of the backup supers certainly don't contain good data:
> xfs_db> sb 1
> xfs_db> p
> magicnum = 0xf6b89fbf
> blocksize = 1483932129
> dblocks = 15694009933101722137
> rblocks = 11068626756016902811
> rextents = 1593063622148300128
...
> xfs_db> sb 2
> xfs_db> p
> magicnum = 0x41474341
> blocksize = 1195590471
> dblocks = 4847921951085253716
> rblocks = 4846789398308864835
> rextents = 4702132125296707412
...
which is why it couldn't find any valid/matching backups. The stated AG size
does look correct, though, for the overall size of the filesystem as stated in
SB 0.
Is there more to this story? Did something "interesting" happen with the
underlying storage? Or with the filesystem prior to this problem?
does "blkid /dev/dm-24" say anything other than "xfs filesystem?"
-Eric
|