public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Sean Caron <scaron@umich.edu>
Cc: linux-xfs@vger.kernel.org
Subject: Re: XFS disaster recovery
Date: Wed, 2 Feb 2022 13:44:30 +1100	[thread overview]
Message-ID: <20220202024430.GZ59729@dread.disaster.area> (raw)
In-Reply-To: <CAA43vkV_nDTJjXqtWw-jpc8KVWwa2jQ8-2bNbNJZBcsBSHV8dw@mail.gmail.com>

On Tue, Feb 01, 2022 at 08:20:45PM -0500, Sean Caron wrote:
> Thank you for the detailed response, Dave! I downloaded and built the
> latest xfsprogs (5.14.2) and tried to run a metadump with the
> parameters:
> 
> xfs_metadump -g -o -w /dev/md4 /exports/home/work/md4.metadump
> 
> It says:
> 
> Metadata CRC error detected at 0x56384b41796e, xfs_agf block 0x4d7fffd948/0x1000
> xfs_metadump: cannot init perag data (74). Continuing anyway.
> 
> It starts counting up inodes and gets to "Copied 418624 of 83032768
> inodes (1 of 350 AGs)"
> 
> The it stops with an error:
> 
> xfs_metadump: inode 2216156864 has unexpected extents

Not promising - that's a device inode (blk, chr, fifo or sock) that
appears to have extents in the data fork. That's indicative of the
inode cluster containing garbage, but unfortunately the error
propagation from a bad inode appears to abort the rest of the
metadump.

That looks like a bug in metadump to me.

Let me confirm this and work out how it should behave and I'll
send you a patch to avoid this issue.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

  reply	other threads:[~2022-02-02  2:48 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-01 23:07 XFS disaster recovery Sean Caron
2022-02-01 23:33 ` Dave Chinner
2022-02-02  1:20   ` Sean Caron
2022-02-02  2:44     ` Dave Chinner [this message]
2022-02-02  7:42       ` [PATCH] metadump: handle corruption errors without aborting Dave Chinner
2022-02-02 18:49         ` Sean Caron
2022-02-02 19:43           ` Sean Caron
2022-02-02 20:18             ` Sean Caron
2022-02-02 22:05               ` Dave Chinner
2022-02-02 23:45                 ` Sean Caron
2022-02-06 22:34                   ` Dave Chinner
2022-02-07 21:42                     ` Sean Caron
2022-02-07 22:34                       ` Dave Chinner
2022-02-07 22:03   ` XFS disaster recovery Sean Caron
2022-02-07 22:33     ` Dave Chinner
2022-02-07 22:56       ` Sean Caron
2022-02-08  1:51         ` Dave Chinner
2022-02-08 15:46           ` Sean Caron
2022-02-08 20:56             ` Dave Chinner
2022-02-08 21:24               ` Sean Caron

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=20220202024430.GZ59729@dread.disaster.area \
    --to=david@fromorbit.com \
    --cc=linux-xfs@vger.kernel.org \
    --cc=scaron@umich.edu \
    /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