[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]