From: Eric Sandeen <sandeen@sandeen.net>
To: xfs@oss.sgi.com
Subject: Re: xfs_repair couldn't verify primary superblock
Date: Wed, 20 Apr 2016 16:13:35 -0400 [thread overview]
Message-ID: <5717E2EF.1080902@sandeen.net> (raw)
In-Reply-To: <d738a94784a0426e97752f92f38325a0@ul-exc-pr-mbx11.ulaval.ca>
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
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2016-04-20 20:13 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-20 17:50 xfs_repair couldn't verify primary superblock Stéphane Larose
2016-04-20 20:13 ` Eric Sandeen [this message]
2016-04-21 14:42 ` Stéphane Larose
2016-04-21 18:34 ` Eric Sandeen
2016-04-22 13:53 ` Stéphane Larose
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5717E2EF.1080902@sandeen.net \
--to=sandeen@sandeen.net \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox