From: Brian Foster <bfoster@redhat.com>
To: Emmanuel Florac <eflorac@intellique.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: xfs_repair keeps reporting errors
Date: Fri, 1 Nov 2019 06:45:51 -0400 [thread overview]
Message-ID: <20191101104551.GB59146@bfoster> (raw)
In-Reply-To: <20191031154049.166549a3@harpe.intellique.com>
On Thu, Oct 31, 2019 at 03:40:49PM +0100, Emmanuel Florac wrote:
> Hi,
>
> I just had a problem with a RAID array, now that the rebuild process
> is complete, as I run xfs_repair (v 5.0) again and again it keeps
> reporting problems (here running xfs_repair for the 3rd time in a row):
>
Problems with the same inodes or the same general issue with different
inodes after repeated repair runs?
What kind of RAID event was involved? Was the filesystem known healthy
prior to the event?
>
> bad CRC for inode 861144976062
> bad magic number 0x0 on inode 861144976062
> bad magic number 0x0 on inode 217316006460
> bad version number 0x0 on inode 217316006460
> inode identifier 0 mismatch on inode 217316006460
> bad version number 0x0 on inode 861144976062
> bad CRC for inode 217316006461
> bad magic number 0x0 on inode 217316006461
> inode identifier 0 mismatch on inode 861144976062
> bad version number 0x0 on inode 217316006461
> inode identifier 0 mismatch on inode 217316006461
> bad CRC for inode 217316006462
> bad magic number 0x0 on inode 217316006462
> bad CRC for inode 861144976063
> bad magic number 0x0 on inode 861144976063
> bad version number 0x0 on inode 861144976063
> bad version number 0x0 on inode 217316006462
> inode identifier 0 mismatch on inode 217316006462
> bad CRC for inode 217316006463
> bad magic number 0x0 on inode 217316006463
> inode identifier 0 mismatch on inode 861144976063
> bad version number 0x0 on inode 217316006463
> inode identifier 0 mismatch on inode 217316006463
>
> Is there anything else to do?
>
I think it's hard to say what might be going on here without some view
into the state of the fs. Perhaps some large chunk of the fs has been
zeroed given all of the zeroed out on-disk inode fields? We'd probably
want to see a metadump of the fs to get a closer look.
Brian
> --
> ------------------------------------------------------------------------
> Emmanuel Florac | Direction technique
> | Intellique
> | <eflorac@intellique.com>
> | +33 1 78 94 84 02
> ------------------------------------------------------------------------
next prev parent reply other threads:[~2019-11-01 10:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-31 14:40 xfs_repair keeps reporting errors Emmanuel Florac
2019-11-01 10:45 ` Brian Foster [this message]
2019-11-04 13:31 ` Emmanuel Florac
2019-11-04 17:21 ` Eric Sandeen
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=20191101104551.GB59146@bfoster \
--to=bfoster@redhat.com \
--cc=eflorac@intellique.com \
--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).