linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Foster <bfoster@redhat.com>
To: Jason <jncw@tpg.com.au>
Cc: linux-xfs@vger.kernel.org
Subject: Re: fatal error -- couldn't map inode 4324730417, err = 117 (Big Noob at this please help)
Date: Thu, 9 Aug 2018 07:14:37 -0400	[thread overview]
Message-ID: <20180809111437.GB21030@bfoster> (raw)
In-Reply-To: <5290c36d-ade4-c74d-c763-9c2fb0dcb126@tpg.com.au>

On Thu, Aug 09, 2018 at 05:24:21PM +1000, Jason wrote:
> Gday all
> 
>   Having a problem with an XFS formatted drive and hope someone can help. On
> unraid, got a format error, ran xfs_repair with the -L prefix (4.15 i think
> that whats built in),got the fatal error above and the unraid people sent me
> over here. If somebody could help that would be great thanks . here is the
> output
> 
> 
> Phase 1 - find and verify superblock...
>         - block cache size set to 738560 entries
...
> Phase 6 - check inode connectivity...
>         - resetting contents of realtime bitmap and summary inodes
>         - traversing filesystem ...
...
>         - agno = 2
> bad hash table for directory inode 4305076930 (no data entry): rebuilding
> rebuilding directory inode 4305076930
> Invalid inode number 0x0
> xfs_dir_ino_validate: XFS_ERROR_REPORT
> 
> fatal error -- couldn't map inode 4324730417, err = 117

I wonder if this is one of those weird/transient verifier issues we had
from transferring over libxfs code into places where it might trip up
repair from dealing with corrupt objects. I don't recall the exact
signature(s) of that error (or affected releases), but the best first
suggestion is probably to try the latest xfs_repair.

Note that if you're running in a controlled environment where it is
difficult to upgrade or compile xfsprogs, you should be able to create a
metadump, copy the metadump off the system and test out newer repair
executables vs. the (restored) metadump on a development system. If the
latest repair handles the metadump image successfully, you'll still need
to find a way to run it against your original filesystem. If it doesn't,
then perhaps you can share the metadump with a developer to debug.

Brian

> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

      reply	other threads:[~2018-08-09 13:39 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-09  7:24 fatal error -- couldn't map inode 4324730417, err = 117 (Big Noob at this please help) Jason
2018-08-09 11:14 ` Brian Foster [this message]

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=20180809111437.GB21030@bfoster \
    --to=bfoster@redhat.com \
    --cc=jncw@tpg.com.au \
    --cc=linux-xfs@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).