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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox