[pve-devel] [PATCH v3 qemu-server 08/11] blockdev: convert drive_mirror to blockdev_mirror

[DERUMIER, Alexandre]

IMHO this isn't really a cryptographic use case, so I'd not worry too
much about any of that.

basically what we have is the following situation:

- we have some input data (volid+snapname)
- we have a key derived from the input data (block node name)
- we have a value (block node)
- we need to be be able to map back the block node (name) to the input
data

>>sometimes we need to allocate a second block node temporarily for a
>>given input data (right?), 

yes, with a unique volume path in the file-node
 

note that a "block-node" , is a couple of fmt-node (handling
.qcow2,.raw,..)->file-node (with the path to file/block/...


For snapshot rename (current->snap1 for xample), I only switch the file
nodes currently (with the blockdev-reopen), so the fmt-node is not
changing. 

The current behaviour is something like:

1)  fmt-node-current----->file-node-current

take snap1


2)
  a) rename

fmt-node-current-->file-node-snap1
(and delete file-node-current)



 b) create a new fmt node current with snap1 as backing

fmt-node-current2-->file-node-current
      |
      |------------->fmt-node-current---->file-node-snap1


I'm not sure that I can swap both fmt+file couple by another fmt+file
couple for the renaming part.  (blockdev-mirror is doing it for
example)

I'll try to do it to be sure, (do the blockdev-reopen at fmt level).

if it's not possible, 

for filenode, the hash could work 100% as the volid+snapname shouldn't
be in 2 nodes at the same time.

but for fmt-node, it should need a lookup into the graph, to find the
parent of file-node (file-node found with the hash)