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@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
