xfs
[Top] [All Lists]

Re: xfs_repair taking a long time

To: xfs@xxxxxxxxxxx
Subject: Re: xfs_repair taking a long time
From: "Ashley Oviatt" <ashovi@xxxxxxxxx>
Date: Fri, 20 Jun 2008 13:04:54 +0000
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=wSrG7v44Y3gMTfwYpmF5Ke+rbb7rtXdpauP34XjimOQ=; b=okkkq7ydDaktXjlvtmAsZIZn/axCqlFRt0pvE8kN19Bsj3Wy6YDrUbZMUb48Rs1r7d KE7AeXSDfifLXq8MwlQ7qIuBK7p3H7N1EFgrxo3qPdHnDsRzp7s+CdwgN/tAH1iuQ/fL WcuxKmQA08o8WIofqGkJUSLBVxmy2CMb3jNsY=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=wnoSbMHapyLEPi5EROK5vJjS8yTZ//L1lm4kFZV88V6AGn3qGldM7ADqmFelkABHCg q3fITKrd3oTMVAoyEM24krLIA3RdV6nbvNXV1KBk4Xzz2+rOZL5ksUrCypmHeN66oP32 bwnKGj8tFgNKfKOpk4cl/OQz5owONDc21Yu3M=
In-reply-to: <485AD667.1060402@xxxxxxxxx>
References: <485AD667.1060402@xxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
I have run xfs_metadump on the array and here is the output:

root@slax:~# xfs_metadump -V
xfs_metadump version 2.9.7
root@slax:~# xfs_metadump /dev/sda /root
xfs_metadump: unexpected XFS SB magic number 0x00000000
xfs_metadump: read failed: Invalid argument
xfs_metadump: data size check failed
cache_node_purge: refcount was 1, not zero (node=0x80e2670)
xfs_metadump: cannot read root inode (22)
xfs_metadump: bad superblock magic number 0, giving up

It looks like the superblock got corrupted, and xfs_repair can't find
another one to fix it.

Any ideas on how to get it back?

Ashley

On 6/19/08, Ash <ashovi@xxxxxxxxx> wrote:
> I am having the same problem as the person in this thread:
>
>
> Which is xfs_repair has been running for 16 hours on a 1 TB raid array.
> It gave the same errors as this thread, saying that it could not use any
> of the super blocks it found. The last email in the thread says:
>
> -----------------------------------------
>
> xfs-repair did find candidate secondary superblocks - it discarded them
> for some reason or another. If they were ok, all repair would have done
> is copied them to block zero and then continued.
>
> I'm suggesting that you manually do this step, and then see if repair
> will run.
>
>  >    Before wrapping this up, if you could just clarify a couple
> things.  If I
>  >    look at the bytes at the beginning of each physical part of the LVM's,
>  >    what am I looking for?  "XFSB"?
>
> yes.
>
>  >    If I do find that byte string, why
>  >    couldn't xfs_repair find it when it did the scan and what do I do
> with it
>  >    if I do find one?
>
> As I said above, xfs-repair did find some, but rejected them for some
> (unknown) reason. if you find one, copy it over block zero of the partition,
> and see if repair will run. Like I said, though, you'll probably want to
> back up th partition first, or at least run repair in no-modify mode.
>
> --------------------------------------
>
> The poster, Dave Chinner, says to manually copy the superblock to the
> right place, but not how to do it. I am familiar with dd, but would like
> to know the exact command or steps to take to replace the primary
> superblock manually with a secondary superblock.
>
> Ashley
>
> (I sent this earlier but I haven't seen it come over the list yet, so
> I'll send it again. Please forgive the duplicate.)
>
>
>


<Prev in Thread] Current Thread [Next in Thread>