Zach Brown wrote:
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.
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
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
