Zach Brown wrote:
quoted text
>> The second use case is to look at the physical layout of blocks on disk
>> for a specific file, use Mark Lord's write_long patches to inject a disk
>> error and then read that file to make sure that we are handling disk IO
>> errors correctly.  A bit obscure, but really quite useful.
> 
> Hmm, yeah, that's interesting.

It would be even better if we could poke holes in metadata, etc, but 
this gives us a reasonable test case.

quoted text
> 
>> We have also used FIBMAP a few times to try and map an observed IO error
>> back to a file. Really slow and painful to do, but should work on any
>> file system when a better method is not supported.
> 
> We're getting off of this FIBMAP topic, but this interests me.  Can we
> explore this a little?  How did you find out about the error without
> having a file to associate with it?  Drive scrubbing, or some such?
> 
> - z

Vladimir extended debugreiserfs to do an optimized reverse mapping scan 
of the disk sector to file/metadata/etc. Definitely worth having that 
ability for any file system.

We also do drive scrubbing, looking for bad sectors. The list of those 
sectors is fed into the reverse mapping code to enable us to gage the 
impact of the IO errors, start recovering the user files, etc.

The scrub code we use takes advantage of the read-verify command (to 
avoid data transfer from the drive to the page cache).

ric
-
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/