xfs
[Top] [All Lists]

Re: xfs_repair segfaults

To: Ole Tange <tange@xxxxxxxxxx>
Subject: Re: xfs_repair segfaults
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Mon, 04 Mar 2013 09:17:51 -0600
Cc: Dave Chinner <david@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <CANU9nT=ALsO3gegWP8vfmYO=CzgPPTRewAfZPYn_en-c2T8ayA@xxxxxxxxxxxxxx>
References: <CANU9nTnvJS50vdQv2K0gKHZPvzzH5EY1qpizJNsqUobrr2juDA@xxxxxxxxxxxxxx> <5131283F.8030704@xxxxxxxxxxx> <20130301223116.GE23616@dastard> <51312C73.5060203@xxxxxxxxxxx> <CANU9nT=ALsO3gegWP8vfmYO=CzgPPTRewAfZPYn_en-c2T8ayA@xxxxxxxxxxxxxx>
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
On 3/4/13 6:47 AM, Ole Tange wrote:
> On Fri, Mar 1, 2013 at 11:32 PM, Eric Sandeen <sandeen@xxxxxxxxxxx> 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
> 

<Prev in Thread] Current Thread [Next in Thread>