Re: [Libguestfs] [PATCH] [v2] WIP: ddrescue mapfile filter
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.