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