[Libguestfs] [PATCH nbdkit 3/4] Add map filter.

[Eric Blake]

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