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
>
>
|