From: Emmanuel Florac <eflorac@intellique.com>
To: Brian Foster <bfoster@redhat.com>
Cc: "Darrick J. Wong" <darrick.wong@oracle.com>,
Dave Chinner <david@fromorbit.com>,
"'linux-xfs@vger.kernel.org'" <linux-xfs@vger.kernel.org>
Subject: Re: Weird xfs_repair error
Date: Tue, 25 Jul 2017 18:44:14 +0200 [thread overview]
Message-ID: <20170725184414.0fe0a1b8@harpe.intellique.com> (raw)
In-Reply-To: <20170724145125.GA12097@bfoster.bfoster>
[-- Attachment #1: Type: text/plain, Size: 2081 bytes --]
Le Mon, 24 Jul 2017 10:51:25 -0400
Brian Foster <bfoster@redhat.com> écrivait:
> There are several fixes in-flight for the issues uncovered by this
> metadump. I think you'll want to include the following 3 patches to
> xfsprogs:
>
> http://marc.info/?l=linux-xfs&m=150047977108174&w=2
> http://marc.info/?l=linux-xfs&m=150040481220074&w=2
> http://marc.info/?l=linux-xfs&m=150040481820076&w=2
>
> Note that the last 2 patches are probably going to be reworked into a
> different implementation. The idea here is ultimately to avoid running
> the verifier in a case where it disrupts xfs_repair, so using this
> intermediate patch series should be good enough to build a custom
> binary that allows xfs_repair to eventually piece the fs back
> together. You could alternatively just hack xfs_dir2_sf_verify() to
> return 0.
>
> Note that I would highly recommend to test whatever you build against
> your metadump before the original fs.
>
You bet... I would even try salvaging files from the unrepaired fs if
possible, but it's probably not workable.
For info I tried the new 4.12, and it fails reliably like this (after
gazillions of metadata errors, etc):
bad hash table for directory inode 4295385906 (no data entry):
rebuilding rebuilding directory inode 4295385906
7f42b14f8780: Badness in key lookup (length)
bp=(bno 0x0, len 4096 bytes) key=(bno 0x0, len 512 bytes)
7f42b14f8780: Badness in key lookup (length)
bp=(bno 0x0, len 4096 bytes) key=(bno 0x0, len 512 bytes)
Invalid inode number 0x0
xfs_dir_ino_validate: XFS_ERROR_REPORT
fatal error -- couldn't map inode 4295400241, err = 117
At least it's always the same error (previous versions were ending with
various logs sizes and errors).
--
------------------------------------------------------------------------
Emmanuel Florac | Direction technique
| Intellique
| <eflorac@intellique.com>
| +33 1 78 94 84 02
------------------------------------------------------------------------
[-- Attachment #2: Signature digitale OpenPGP --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
next prev parent reply other threads:[~2017-07-25 16:44 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-06 13:30 Weird xfs_repair error Emmanuel Florac
2017-07-06 13:48 ` Brian Foster
2017-07-06 14:49 ` Emmanuel Florac
2017-07-06 23:28 ` Dave Chinner
2017-07-07 11:36 ` Emmanuel Florac
2017-07-07 11:50 ` Emmanuel Florac
2017-07-07 15:36 ` Darrick J. Wong
2017-07-10 17:29 ` Emmanuel Florac
2017-07-11 13:23 ` Emmanuel Florac
2017-07-17 17:11 ` Brian Foster
2017-07-24 14:27 ` Emmanuel Florac
2017-07-24 14:51 ` Brian Foster
2017-07-25 16:44 ` Emmanuel Florac [this message]
2017-07-25 17:16 ` Emmanuel Florac
2017-07-25 19:22 ` Brian Foster
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=20170725184414.0fe0a1b8@harpe.intellique.com \
--to=eflorac@intellique.com \
--cc=bfoster@redhat.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.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).