From: Eric Sandeen <sandeen@sandeen.net>
To: Christian Affolter <christian.affolter@purplehaze.ch>
Cc: xfs@oss.sgi.com
Subject: Re: failed to read root inode
Date: Sat, 08 May 2010 10:06:53 -0500 [thread overview]
Message-ID: <4BE57E0D.3020601@sandeen.net> (raw)
In-Reply-To: <4BE55A63.8070203@purplehaze.ch>
Christian Affolter wrote:
> Hi
>
> After a disk crash within a hardware RAID-6 controller and kernel
> freeze, I'm unable to mount an XFS filesystem on top of an EVMS volume:
Are you sure the volume is reassembled correctly? It seems like the
fs has a ton of damage ...
One trick I often recommend is to make a metadata image of the fs
with xfs_metadump / xfs_mdrestore and run repair on that to see
what repair -would- do, but I guess you've already run it on the
real fs.
So if repair isn't making a mountable fs, first suggestion would
be to re-try with the latest version of repair.
> Filesystem "dm-13": Disabling barriers, not supported by the underlying
> device
Honestly, that could be part of the problem too, if a bunch of
disks with write caches all lost them, in the array.
> XFS mounting filesystem dm-13
> Starting XFS recovery on filesystem: dm-13 (logdev: internal)
> XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1599 of file
> fs/xfs/xfs_alloc.c. Caller 0xffffffff8035c58d
> Pid: 13473, comm: mount Not tainted 2.6.26-gentoo #1
...
> XFS: log mount finish failed
So recovery is failing, you could try mount -o ro,norecovery at this
point to see what's still left on the fs... but:
> I tried to repair the filesystem with the help of xfs_repair many times,
> without any luck:
> Filesystem "dm-13": Disabling barriers, not supported by the underlying
> device
> XFS mounting filesystem dm-13
> XFS: failed to read root inode
...
> xfs_check output:
> cache_node_purge: refcount was 1, not zero (node=0x820010)
> xfs_check: cannot read root inode (117)
That's a bit of an odd root inode number, I think, which
makes me think maybe there are still serious problems.
> Are there any other ways to fix the unreadable root inode or to restore
> the remaining data?
>
>
> Environment informations:
> Linux Kernel: 2.6.26-gentoo (x86_64)
> xfsprogs: 3.0.3
Those are both pretty old at this point, I can't say there is anything
specific in newer xfsprogs, but I'd probably give that a shot first.
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2010-05-08 15:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-08 12:34 failed to read root inode Christian Affolter
2010-05-08 15:06 ` Eric Sandeen [this message]
2010-05-09 14:53 ` Christian Affolter
2010-05-11 10:05 ` Christian Affolter
2010-05-08 22:53 ` Stan Hoeppner
2010-05-09 13:28 ` Emmanuel Florac
2010-05-09 14:53 ` Stan Hoeppner
2010-05-09 15:34 ` Emmanuel Florac
2010-05-10 1:09 ` Eric Sandeen
2010-05-09 15:35 ` Christian Affolter
2010-05-09 15:59 ` Emmanuel Florac
2010-05-09 17:34 ` Stan Hoeppner
2010-05-09 18:03 ` Roger Willcocks
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=4BE57E0D.3020601@sandeen.net \
--to=sandeen@sandeen.net \
--cc=christian.affolter@purplehaze.ch \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.