[Top] [All Lists]

Re: xfs_repair of critical volume

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: xfs_repair of critical volume
From: Eli Morris <ermorris@xxxxxxxx>
Date: Sun, 14 Nov 2010 20:09:35 -0800
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20101114110559.GB22876@dastard>
References: <75C248E3-2C99-426E-AE7D-9EC543726796@xxxxxxxx> <4CCD3CE6.8060407@xxxxxxxxxxxxxxxxx> <864DA9C9-B4A4-4B6B-A901-A457E2B9F5A5@xxxxxxxx> <201011121422.28993@xxxxxx> <BE08758D-20B4-48F1-8BF7-FCD0341D38C2@xxxxxxxx> <20101114110559.GB22876@dastard>
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....
> Cheers,
> Dave.
> -- 
> Dave Chinner
> david@xxxxxxxxxxxxx

Thanks a lot Dave,

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?


thanks again,


<Prev in Thread] Current Thread [Next in Thread>