public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Ole Tange <tange@binf.ku.dk>
Cc: xfs@oss.sgi.com
Subject: Re: xfs_repair segfaults
Date: Mon, 04 Mar 2013 09:17:51 -0600	[thread overview]
Message-ID: <5134BB1F.4020207@sandeen.net> (raw)
In-Reply-To: <CANU9nT=ALsO3gegWP8vfmYO=CzgPPTRewAfZPYn_en-c2T8ayA@mail.gmail.com>

On 3/4/13 6:47 AM, Ole Tange wrote:
> On Fri, Mar 1, 2013 at 11:32 PM, Eric Sandeen <sandeen@sandeen.net> wrote:
> 
>> Ole, you can xfs_mdrestore your metadump image and run test repairs on the result,
>> if you want a more realistic "dry run" of what repair would do.
> 
> I have never run xfs_mdrestore before.
> 
> From the man page:
> 
>        xfs_mdrestore should not be used to restore metadata onto an
> existing filesystem unless you are completely certain the  target  can
>  be destroyed.
> 
> It is unclear to me if you are suggesting me to do:
> 
>   xfs_mdrestore the-already-created-dump /dev/md5p1

no. definitely not. :)

> followed by xfs_repair. Or if you want me to restore the metadata on
> another 100 TB partition (I do not have that available).

Nope - to a sparse file, on a filesystem which can hold a file with
100T offsets - like xfs.

> Maybe you have a trick so that it can be restored on some smaller
> block device, so I do not need the 100 TB partition, but I will still
> be able to see how many files are being removed? If you have such a
> trick, consider including it in the manual.

Probably worth doing, or putting in the xfs faq.

Basically, if you do:

# xfs_mdatadump -o /dev/whatever metadump.file
# xfs_mdrestore metadump.file xfsfile.img

or

# xfs_metadump -o /dev/whatever - | xfs_mdrestore - xfsfile.img

then you can xfs_repair xfsfile.img, without the -n, see what happens,
mount the image as loopback, see what's changed, etc, to see what
xfs_repair really would do with your actual filesystem.

(although, if things are so badly corrupted that metadump gets confused,
it's not as good a test).

The metadump only contains *metadata* so if you read any file on
the mounted loopback image, you just get 0s back.

> Also I would love if xfs_repair had an option to copy the changed
> sectors to a file, so it would be easy to revert. E.g:
> 
>   xfs_repair --backup backup.file /dev/sda1
> 
> and if the repair did not work out, then you could revert using:
> 
>   xfs_repair --revert backup.file /dev/sda1
> 
> and be back at your starting state.

That would be nice.  But as soon as you have mounted the result
and made any change at all to the fs, reverting in this manner wouldn't be
safe anymore.

-Eric

> 
> /Ole
> 

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  reply	other threads:[~2013-03-04 15:17 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-28 15:22 xfs_repair segfaults Ole Tange
2013-02-28 18:48 ` Eric Sandeen
2013-03-01  9:37   ` Ole Tange
2013-03-01 16:46     ` Eric Sandeen
2013-03-04  9:00       ` Ole Tange
2013-03-04 15:20         ` Eric Sandeen
2013-03-08 10:21           ` Ole Tange
2013-03-08 20:32             ` Eric Sandeen
2013-03-12 10:41               ` Ole Tange
2013-03-12 14:40                 ` Eric Sandeen
2013-03-12 11:37             ` Ole Tange
2013-03-12 14:47               ` Eric Sandeen
2013-03-01 11:17 ` Dave Chinner
2013-03-01 12:24   ` Ole Tange
2013-03-01 20:53     ` Dave Chinner
2013-03-04  9:03       ` Ole Tange
2013-03-04 23:23         ` Dave Chinner
2013-03-08 10:09           ` Ole Tange
2013-03-01 22:14 ` Eric Sandeen
2013-03-01 22:31   ` Dave Chinner
2013-03-01 22:32     ` Eric Sandeen
2013-03-01 23:55       ` Eric Sandeen
2013-03-04 12:47       ` Ole Tange
2013-03-04 15:17         ` Eric Sandeen [this message]
2013-03-04 23:11           ` Dave Chinner
  -- strict thread matches above, loose matches on Subject: below --
2013-05-06 12:06 Xfs_repair segfaults Filippo Stenico
2013-05-06 14:34 ` Eric Sandeen
2013-05-06 15:00   ` Filippo Stenico
     [not found]     ` <CADNx=Kv0bt3fNGW8Y24GziW9MOO-+b7fBGub4AYP70b5gAegxw@mail.gmail.com>
2013-05-07 13:20       ` Eric Sandeen
2013-05-07 13:36         ` Filippo Stenico
2013-05-07 18:20           ` Filippo Stenico
2013-05-08 17:30             ` Filippo Stenico
2013-05-08 17:42               ` Filippo Stenico
2013-05-08 23:39               ` Dave Chinner
2013-05-09 15:11                 ` Filippo Stenico
2013-05-09 17:22                   ` Filippo Stenico
2013-05-09 22:39                     ` Dave Chinner
     [not found]                       ` <CADNx=KuQjMNHUk6t0+hBZ5DN6s=RXqrPEjeoSxpBta47CJoDgQ@mail.gmail.com>
2013-05-10 11:00                         ` Filippo Stenico
2013-05-09 22:37                   ` Dave Chinner

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=5134BB1F.4020207@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=tange@binf.ku.dk \
    --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