On Nov 15, 2010, at 4:04 PM, Dave Chinner wrote: > On Sun, Nov 14, 2010 at 08:09:35PM -0800, Eli Morris wrote: >> On Nov 14, 2010, at 3:05 AM, Dave Chinner wrote: >>> On Fri, Nov 12, 2010 at 03:01:47PM -0800, Eli Morris wrote: >>>> On Nov 12, 2010, at 5:22 AM, Michael Monnerie wrote: >>>>> On Freitag, 12. November 2010 Eli Morris wrote: >>>>>> The filesystem must be pointing to files that don't exist, or >>>>>> something like that. Is there a way to fix that, to say, remove >>>>>> files that don't exist anymore, sort of command? I thought that >>>>>> xfs_repair would do that, but apparently not in this case. >>>>> >>>>> The filesystem is not optimized for "I replace part of the disk contents >>>>> with zeroes" and find that errors. You will have to look in each file if >>>>> it's contents are still valid, or maybe bogus. >>> .... >>>> Let me see if I can give you and everyone else a little more >>>> information and clarify this problem somewhat. And if there is >>>> nothing practical that can be done, then OK. What I am looking for >>>> is the best PRACTICAL outcome here given our resources and if >>>> anyone has an idea that might be helpful, that would be awesome. I >>>> put practical in caps, because that is the rub in all this. We >>>> could send X to a data recovery service, but there is no money for >>>> that. We could do Y, but if it takes a couple of months to >>>> accomplish, it might be better to do Z, even though Z is riskier >>>> or deletes some amount of data, because it is cheap and only takes >>>> one day to do.. >>> >>> Well, the best thing you can do is work out where in the block >>> device the zeroed range was, and then walk the entire filesystem >>> running xfs_bmap on every file to work out where their physical >>> extents are. i.e. build a physical block map of the good and bad >>> regions, then find what files have bits in the bad regions. >>> I've seen this done before with a perl script, and shouldn't take >>> more than a few hours to write and run.... >> >> I think that's a really good suggestion. I was thinking along >> those same lines myself. I understand how I would find where the >> files are located using xfs_bmap. Do you know which command I >> would use to find where the 'bad region' is located, so I can >> compare them to the file locations? > > There isn't a command to find the 'bad region'. The bad region(s) > need to be worked out based on the storage geometry. e.g. if you had > a linear concat of 3 luns ilke so: > > lun logical offset length > 0 0GB 500GB > 1 500GB 500GB > 2 1000GB 500GB > > And you lost lun 1, then your bad region is from 500GB-1000GB, and > it's easy to map that. However, if you have a RAID5/6 of those luns, > it gets a whole lot more complex because you need to know how the > RAID layout works (e.g. left-asymmetric) to work out where all the > parity is stored for each stripe and hence which disk contains data. > > I'm not sure what your layout is, but you should be able to > calculate the bad regions specifically from the geometry of the > storage and your knowledge of which lun got zeroed.... > > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx Hi Dave, Thanks a lot for your help. I looked at the man page and elsewhere for this info and can't find what this means: extent: [startoffset..endoffset]: startblock..endblock I understand what an offset would be, but what the heck is a startoffset and an endoffset? Is the formula for the location of the file: startoffset + startblock through endoffset + endblock, where the blocks and the offsets are in 512 bytes? So this file: 0: [0..1053271]: 5200578944..5201632215 would be contained from: beginning: (0 + 5200578944) * 512 bytes ending: (1053271 + 5201632215) * 512 bytes Is that correct? thanks again, Eli _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
