--- Begin Message ---
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)
--- End Message ---
_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
