public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Eli Morris <ermorris@ucsc.edu>
Cc: xfs@oss.sgi.com
Subject: Re: xfs_repair of critical volume
Date: Mon, 01 Nov 2010 19:14:22 -0500	[thread overview]
Message-ID: <4CCF57DE.9080502@sandeen.net> (raw)
In-Reply-To: <00C51060-5205-4E95-B27C-8E31468ED45C@ucsc.edu>

On 11/1/10 6:32 PM, Eli Morris wrote:
> 
> On Nov 1, 2010, at 3:21 PM, Eric Sandeen wrote:
> 
>> On 10/31/10 2:54 AM, Eli Morris wrote:
>>> I have a large XFS filesystem (60 TB) that is composed of 5
>>> hardware RAID 6 volumes. One of those volumes had several drives
>>> fail in a very short time and we lost that volume. However, four
>>> of the volumes seem OK. We are in a worse state because our
>>> backup unit failed a week later when four drives simultaneously
>>> went offline. So we are in a bad very state. I am able to mount
>>> the filesystem that consists of the four remaining volumes. I was
>>> thinking about running xfs_repair on the filesystem in hopes it
>>> would recover all the files that were not on the bad volume,
>>> which are obviously gone. Since our backup is gone, I'm very
>>> concerned about doing anything to lose the data that will still
>>> have. I ran xfs_repair with the -n flag and I have a lengthly
>>> file of things that program would do to our filesystem. I don't
>>> have the expertise to decipher the output and figure out if 
>>> xfs_repair would fix the filesystem in a way that would retain
>>> our remaining data or if it would, let's say t!
>> 
>> 
>> One thing you could do is make an xfs_metadump image,
>> xfs_mdrestore it to a sparse file, and then do a real xfs_repair
>> run on that. You can then mount the repaired image and see what's
>> there. So from a metadata perspective, you can do a real-live
>> repair run on an image, and see what happens.
>> 
>> -Eric
> 
> Hi Eric,
> 
> Thanks for the suggestion. I tried is out and this is what happened
> when I ran xfs_mdrestore:
> 
> # xfs_mdrestore -g xfs_dump_image vol5_dump xfs_mdrestore: cannot set
> filesystem image size: File too large #
> 
> Any ideas? Is the file as large as the volume or something? I think
> you had a really good suggestion. If you know how to make this work,
> I think that would be great.

Guessing you tried to create it on an ext3 filesystem?

The file has a maximum offset == the size of the filesystem, but it is
sparse so does not take up that much disk space.

ext3 can't go beyond a 2T file offset.

Making the file "dump_image" on an xfs filesystem should do the trick.

-Eric

> thanks,
> 
> Eli
> 
> 

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

  reply	other threads:[~2010-11-02  0:13 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-31  7:54 xfs_repair of critical volume Eli Morris
2010-10-31  9:54 ` Stan Hoeppner
2010-11-12  8:48   ` Eli Morris
2010-11-12 13:22     ` Michael Monnerie
2010-11-12 22:14       ` Stan Hoeppner
2010-11-13  8:19         ` Emmanuel Florac
2010-11-13  9:28           ` Stan Hoeppner
2010-11-13 15:35             ` Michael Monnerie
2010-11-14  3:31               ` Stan Hoeppner
2010-12-04 10:30         ` Martin Steigerwald
2010-12-05  4:49           ` Stan Hoeppner
2010-12-05  9:44             ` Roger Willcocks
2010-11-12 23:01       ` Eli Morris
2010-11-13 15:25         ` Michael Monnerie
2010-11-14 11:05         ` Dave Chinner
2010-11-15  4:09           ` Eli Morris
2010-11-16  0:04             ` Dave Chinner
2010-11-17  7:29               ` Eli Morris
2010-11-17  7:47                 ` Dave Chinner
2010-11-30  7:22                   ` Eli Morris
2010-12-02 11:33                     ` Michael Monnerie
2010-12-03  0:58                       ` Stan Hoeppner
2010-12-04  0:43                       ` Eli Morris
2010-10-31 14:10 ` Emmanuel Florac
2010-10-31 14:41   ` Steve Costaras
2010-10-31 16:52 ` Roger Willcocks
2010-11-01 22:21 ` Eric Sandeen
2010-11-01 23:32   ` Eli Morris
2010-11-02  0:14     ` Eric Sandeen [this message]
  -- strict thread matches above, loose matches on Subject: below --
2010-10-31 19:56 Eli Morris
2010-10-31 20:40 ` Emmanuel Florac
2010-11-01  3:40   ` Eli Morris
2010-11-01 10:07     ` Emmanuel Florac
2010-10-31 21:10 ` Steve Costaras
2010-11-01 15:03 ` Stan Hoeppner

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=4CCF57DE.9080502@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=ermorris@ucsc.edu \
    --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