lkml.org 
[lkml]   [2007]   [Oct]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 0/6][RFC] Cleanup FIBMAP
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-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/

\
 
 \ /
  Last update: 2007-10-31 18:21    [W:0.093 / U:0.560 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site