xfs
[Top] [All Lists]

Re: XFS_REPAIR on LVM partition

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: XFS_REPAIR on LVM partition
From: Rafael Weingartner <rafaelweingartner@xxxxxxxxx>
Date: Wed, 18 Dec 2013 21:29:56 -0200
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7Xqad+MWo2E6YKxr5ibHEVTqc9DBn+xYsTvdKLHfo3g=; b=FqtTyT1KhRxVPL0tdq8Qfwaew/vqiZfmabeq6UAJgHq2r6SzQJb1NiddV1cnElRbHz ukNJjnPM6dTPN4ZQURcoG7j2AkA8QjpmwKdeg37NAXtc1dVrKe+CJehuQ5E63WFr8MzQ NSvaBVimqLgkKZzuCH11KbtmhhSjMnAUnRpkofhWGfmwUIU9JcDdLWvDDfOWFp9gvdwq po+TOrmdl4zbKS3BUIdgCXp/3xLm04ia84IBkHnNlR9RTtfuV3qIpLtMVXQEa7fsR3Ay Ic/aXpfaVrLFGJu2wpEujTzI/KXx9my18gXXro5xAKrXBcv7VWOvR8q//PK+xMgJtwVL yz0A==
In-reply-to: <20131218213434.GK31386@dastard>
References: <CAG97raf61XGnTakrYjcfv9cjM6CTVdEEB3wQK+wOBvpowWO3Cw@xxxxxxxxxxxxxx> <20131216000141.GU31386@dastard> <CAG97radg3xd8-G2qChh2BOfH8R6N4kWH3qn3ivukxrkFVrt=rA@xxxxxxxxxxxxxx> <20131216030537.GX31386@dastard> <CAG97racd-UhUqhVLcsbjqZt51iTEaHKaQNMkvQFnznH8X8wOUQ@xxxxxxxxxxxxxx> <20131216125402.GB10988@dastard> <CAG97raeP-0QEhhYjDX_DDxzS3TN_brRSU6G+j-+V3KEuJ7Ym6Q@xxxxxxxxxxxxxx> <CAG97raf7Na5UwzREJ_C9nYJ64r7PPwkhp_qcPiGVnKqu+ujAgw@xxxxxxxxxxxxxx> <20131218213434.GK31386@dastard>
[ cc'd the XFS list again - please keep problem triage on the public
lists so that more than one person can help you. ]

My bad, I am sorry, sometimes I forget to press the reply to all button. 

It's still possible to recover, but more info is needed first.
Can you get xfs_db to dump the primary and a couple of secondary
superblocks?

I am glad to hear that, I have actually already extracted the files that I needed using UFS explorer, but I still would like to restore the filesystem if it is possible. 

Output of "xfs_db -c "sb 0" -c p -c "sb 2" -c p -c "sb 7" -c p <dev>"

xfs_db: cannot init perag data (117)
magicnum = 0x58465342
blocksize = 4096
dblocks = 131072000
rblocks = 0
rextents = 0
uuid = 430d1253-0d52-401b-b6bd-42e23bb56bc3
logstart = 67108868
rootino = 128
rbmino = 129
rsumino = 130
rextsize = 1
agblocks = 32768000
agcount = 4
rbmblocks = 0
logblocks = 64000
versionnum = 0xb4a4
sectsize = 512
inodesize = 256
inopblock = 16
fname = "\000\000\000\000\000\000\000\000\000\000\000\000"
blocklog = 12
sectlog = 9
inodelog = 8
inopblog = 4
agblklog = 25
rextslog = 0
inprogress = 0
imax_pct = 25
icount = 256
ifree = 200
fdblocks = 127617831
frextents = 0
uquotino = 0
gquotino = 0
qflags = 0
flags = 0
shared_vn = 0
inoalignmt = 2
unit = 0
width = 0
dirblklog = 0
logsectlog = 0
logsectsize = 0
logsunit = 1
features2 = 0xa
bad_features2 = 0xa
magicnum = 0x58465350
blocksize = 4096
dblocks = 7566328849834176030
rblocks = 70481084416
rextents = 5638878729879945216
uuid = 5de3e560-0f52-401b-854a-acfc3bb56bfb
logstart = 7566047375040578052
rootino = 18374686479671613439
rbmino = 18446744071377518559
rsumino = null
rextsize = 1
agblocks = 32768000
agcount = 4
rbmblocks = 1073782799
logblocks = 64000
versionnum = 0xa4a4
sectsize = 512
inodesize = 267
inopblock = 16
fname = "3\367\356\036\000\000\000`i\000\000\000"
blocklog = 66
sectlog = 64
inodelog = 190
inopblog = 133
agblklog = 27
rextslog = 3
inprogress = 1
imax_pct = 25
icount = 0
ifree = 72057594037927936
fdblocks = 131054064
frextents = 5891388165771235349
uquotino = 13746228866238942976
gquotino = 13746228866238942976
qflags = 0xd0de
flags = 0x17
shared_vn = 97
inoalignmt = 33554434
unit = 418391552
width = 0
dirblklog = 0
logsectlog = 0
logsectsize = 0
logsunit = 506003457
features2 = 0x8
bad_features2 = 0xa
bad allocation group number 7
magicnum = 0x58465350
blocksize = 4096
dblocks = 7566328849834176030
rblocks = 70481084416
rextents = 5638878729879945216
uuid = 5de3e560-0f52-401b-854a-acfc3bb56bfb
logstart = 7566047375040578052
rootino = 18374686479671613439
rbmino = 18446744071377518559
rsumino = null
rextsize = 1
agblocks = 32768000
agcount = 4
rbmblocks = 1073782799
logblocks = 64000
versionnum = 0xa4a4
sectsize = 512
inodesize = 267
inopblock = 16
fname = "3\367\356\036\000\000\000`i\000\000\000"
blocklog = 66
sectlog = 64
inodelog = 190
inopblog = 133
agblklog = 27
rextslog = 3
inprogress = 1
imax_pct = 25
icount = 0
ifree = 72057594037927936
fdblocks = 131054064
frextents = 5891388165771235349
uquotino = 13746228866238942976
gquotino = 13746228866238942976
qflags = 0xd0de
flags = 0x17
shared_vn = 97
inoalignmt = 33554434
unit = 418391552
width = 0
dirblklog = 0
logsectlog = 0
logsectsize = 0
logsunit = 506003457
features2 = 0x8
bad_features2 = 0xa



On Wed, Dec 18, 2013 at 7:34 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote:
[ cc'd the XFS list again - please keep problem triage on the public
lists so that more than one person can help you. ]

On Mon, Dec 16, 2013 at 02:53:03PM -0200, Rafael Weingartner wrote:
> Today, I let the command xfs_repair /dev/... ran till it finished, I got
> the following messages:
>
> Phase 1 - Find and verify superblock ....
> > Could not verify primary superblock - not enough secondary superblocks
> > with matching geometry!!

The primary superblock dump looked valid, but it it couldn't find
matching secondary superblocks from the contents of the primary that
it found.

> > attempting to find a secondary superblock.....
> > ...
> > ..
> > ...
> > ...
> > found candidate secondary superblock....
> > unable to verify superblock, continuing....

And it found blocks with the correct superbloc magic numbers, but
they don't match the primary superblock that was found.

> > found candidate secondary superblock....
> > unable to verify superblock, continuing...
> > ...
> > ...
> > ..............................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................Sorry,
> > could not find valid secondary superblock
> > Exiting now.
>
>
> Should I upgrade the xfsprogs and try to run the xfs_repair again?
> Or does that message mean that there is no way of recovering the filesystem?

It's still possible to recover, but more info is needed first.
Can you get xfs_db to dump the primary and a couple of secondary
superblocks?

# xfs_db -c "sb 0" -c p -c "sb 2" -c p -c "sb 7" -c p <dev>

And post the output?

Cheers,

Dave.
--
Dave Chinner
david@xxxxxxxxxxxxx



--
Rafael Weingärtner
<Prev in Thread] Current Thread [Next in Thread>