Re: [Libguestfs] [PATCH nbdkit 3/4] Add map filter.
On 08/01/2018 05:38 AM, Richard W.M. Jones wrote:
On Tue, Jul 31, 2018 at 05:22:32PM -0500, Eric Blake wrote:
> Is there a syntax for explicitly mentioning a subset is unmapped
> even after a larger mapping is applied first (perhaps useful for
> redacting a portion of a disk containing sensitive information)?
It's a good idea for a TODO item, so I'll add it there. At the moment
it's possible to express this in the map file, but only by positively
listing the regions you want to be mapped, not by negatively listing
regions you want unmapped.
>> + * existing +-------------------+
>> + * new +---+
>> + * => split existing mapping into two
>
> should that be 'two/three'?
The existing mapping is split into just two pieces, I think? The
middle bit, hidden by the new mapping, gets discarded.
>> + *
>> + * existing +-----------+
>> + * new +-----+
>> + * => adjust start of existing mapping
>
> or is it really a case that you first split into two, then adjust
> one of the two
I think the comment is correct, unless I'm misunderstanding what you
mean. Note that where the new mapping overlaps the existing mapping,
the existing mapping is discarded (to maintain the invariant).
I was thinking that 'one entry in the list becomes either two or three
entries', rather than your 'one existing entry is split into two
entries, then one of those two entries is further adjusted and/or
replaced by the new entry being added'. Up to you how you word it, the
list management itself makes sense.
>
> When duplicating things, do we want to document that a single
> transaction is carried out in the order seen by the client (where
> aliases at later bytes overwrite any data written into the earlier
> alias in a long transaction), or do we want to put in hedge wording
> that (in the future) a request might be split into smaller regions
> that get operated on in parallel (thereby making the end contents
> indeterminate when writing to two aliases of the same byte in one
> transaction)?
I think I'd rather leave it unspecified. I'll add some caveat text to
the documentation.
Always better to be fuzzy first, where we can tighten later if needed ;)
>> +maps the region starting at byte 1024 and ending at byte
2047
>> +(inclusive) to bytes 2048-3071 in the output.
>
> Since you already support '2k', '2m' and such as shorthands for the
> start, is it worth creating a convenient shorthand for expressing
> '3M-1' for an end rather than having to write out 3145727?
Yeah I thought about that. Unfortunately you quickly get into
needing to write a parser. (Hey, what about "2^20-1"?!)
and to some extent, "(2m, 1m)" solves that a bit nicer than
"2m-3145727"
(that is, start/length is easier to use round numbers than start/end).
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org