[Libguestfs] [PATCH] [v2] WIP: ddrescue mapfile filter

[François Revol]

Hi,

Le 01/05/2020 à 21:41, Eric Blake a écrit :
>> +C<nbdkit-ddrescue-filter> is a filter for L<nbdkit(1)> which overlays
>> +bad blocks according to a GNU L<ddrescue(1)> mapfile.  This is mainly
>> useful
>> +for testing disk images recovered with ddrescue, to detect which files
>> +or filesystem structures are impacted, or attempting fsck on them.
> 
> Oh cool, this sounds very similar to the existing extentlist plugin, but
> with a difference that extentlist uses the input to decide which
> portions of the file are advertised as sparse, while this one uses which
> portions of the file cause EIO errors during read.  Is it worth trying
> to combine the two concepts into one filter, or do we want to keep it
> orthogonal as two separate filters?  Can we teach both filters to reuse
> common code for parsing extent lists in different formats (the
> extentlist format is the same format documented by the nbdkit-sh-plugin
> .extents; yours is the ddrescue format, I am also interested in the
> 'qemu-img map --output=json' format)?  In fact, if we introduce a common
> library for extent list parsing, teaching nbdkit-sh-plugin to accept all
> formats might be useful.
> 
> I ask this because one of my ideas for qemu-nbd and the
> 'qemu:dirty-bitmap:FOO' exposure of a bitmap is to have qemu-nbd report
> EIO for any part of the file not covered by the dirty bitmap.  There is
> no easy way to emulate that in nbdkit yet (since nbdkit does not
> understand anything other than the base:allocation context), but this
> filter plus the nbd plugin would be a way to provide those semantics on
> top of existing qemu-nbd, if this filter could easily parse qemu-img's
> extent list.

Hmm I didn't use qemu-img much, and I don't have much time currently,
but feel free to improve the code. :-)

>> +The above command serves the disk image disk.img and maps the bad
>> +sectors listed in disk.img so that read attempts on them do not return
>> +a valid block full of zeroes.
> 
> Wording suggestion:
> 
> and maps the bad sectors listed in disk.img so that read attempts over
> those portions of the file fail rather than returning a valid block
> containing garbage.

Oh I didn't see this part.

Well actually ddrescue fills the image with zeros when it can't read (or
uses a sparse file which will read as zeros anyway), but yeah, in theory
the filter could be used to read the recovered drive again and skip the
bad blocks, though I'm not sure who would want to do such a silly thing.
So indeed that's the reason I had to write the filter in the first
place. :-D

> Or even make it configurable (via another .config knob) whether bad
> blocks read as zero or cause EIO.

Hmm except for testing I'm not sure who would need this.
A block full of zeroes is perfectly valid data, only higher level
structures (file headers telling there should be something else there)
can determine if the data is wrong or not.

François.