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

[Fiona Ebner]

Am 13.01.25 um 11:47 schrieb DERUMIER, Alexandre via pve-devel:
>>> something like this was what I was afraid of 😉 this basically means
>>> we need to have some way to lookup the nodes based on the structure
>>> of the graph, which probably also means verifying that the structure
>>> matches the expected one (e.g., if we have X snapshots, we expect N
>>> nodes, if we currently have operation A going on, there should be an
>>> extra node, etc.pp. - and then we can "know" that the seventh node
>> >from the bottom must be snapshot 'foobar' ;)). 
> 
> I think it's not a much a problem to follow the graph from top to
> bottom. (as everything attached is have parent-child relationship)
> and
> 
> - for snapshot, we have the snapshot name in the filename
> So we can known if it' a specific snap or the live image.
> 
> 
> for the temporary nodes (when we do block-add, before a mirror or
> switch), we define the nodename, so we don't need to parse the graph
> here.

I do think following the graph structure would be a viable approach too.

>>> relying on $path being >>stable definitely won't work.
> 
> I really don't see why the path couldn't be stable ?
> 
> Over time, if something is changing in qemu (for example, rbd://....
> with a new param),
> it'll only be apply on the new qemu process (after restart or live
> migration), so the path in the block-node will be updated too. (live
> migration will not keep old block-nodes infos, the used value are qemu
> command line arguments)
> 

Upgrading libpve-storage-perl or an external storage plugin while the VM
is running could lead to a different result for path() and thus
breakage, right?

If we do need lookup, an idea to get around the character limit is using
a hash of the information to generate the node name, e.g.
hash("fmt-$volid@$snapname"), hash("file-$volid@$snapname") or whatever
is actually needed as unique information. Even if we only use lowercase
letters, we have 26 base chars, so 26^31 possible values.

So hashes with up to

>>> math.log2(26**31)
145.71363126237387

bits can still fit, which should be more than enough. Even with an
enormous number of 2^50 block nodes (realistically, the max values we
expect to encounter are more like 2^10), the collision probability
(using a simple approximation for the birthday problem) would only be

>>> d=2**145
>>> n=2**50
>>> 1 - math.exp(-(n*n)/(2*d))
1.4210854715202004e-14


> 
> and the file path is the only attribute in a node that you can't
> update.