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
next prev parent 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