linux-kernel - Re: [patch 0/6][RFC] Cleanup FIBMAP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4728B8C5.90607@emc.com>
Date:	Wed, 31 Oct 2007 13:17:57 -0400
From:	Ric Wheeler <ric@....com>
To:	Zach Brown <zab@...bo.net>
CC:	Mike Waychison <mikew@...gle.com>,
	Chris Mason <chris.mason@...cle.com>,
	Anton Altaparmakov <aia21@....ac.uk>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/