> Fabian Grünbichler <f.gruenbich...@proxmox.com> hat am 13.01.2025 10:52 CET > geschrieben: > > > > DERUMIER, Alexandre <alexandre.derum...@groupe-cyllene.com> hat am > > 13.01.2025 09:27 CET geschrieben: > > > > > > > + my $path = PVE::Storage::path($storecfg, $volid); > > > > >>is this guaranteed to be stable? also across versions? and including > > >>external storage plugins? > > > > it can't be different than the value we have use for command line > > generation. But I think that I should use $path directly (It's working > > for block/file , but I think it'll not work with ceph,gluster,...) > > I need to reuse the code used to generated the blockdev commande line. > > > > Another way, maybe a better way,is to parse the tree from the top node > > (the throttle-group) where the name is fixed. and look for fmt|file > > chain attached to this node. > > > > (I just need need to check when we are a doing live renaming, we have 2 > > files nodes, with the newer file node not attached to the tree before > > the switch) > > > > > > > > > + > > > + my $node = find_blockdev_node($nodes, $path, 'fmt'); > > > > >>that one is only added in a later patch.. but I don't think lookups > > >>by path are a good idea, we should probably have a deterministic node > > >>naming concept instead? e.g., encode the drive + snapshot name? > > > > I really would like to have something deterministic but: > > > > - devices node are 31 characters max. (snapshot name can be more big) > > - we can't rename a node (but we are renaming files for snapshot over > > time) > > > > > > As Fiona said, we could have random names and do 1 lookup each time to > > list them. > > > > (I really need to have our own name, because blockdev-reopen, for live > > renaming of files, is not working with autogenerated block# name) > > 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' > ;)). relying on $path being stable definitely won't work.
something more to add to this - if it is impossible to map back using the structure alone, we might need to somehow keep track ourselves for the full livecycle of the VM? e.g., find a way to attach the "volid+snap" information to a block node as metadata, or to add such a mapping inside the VM or alongside it? OTOH, that approach would then break if a user does a manual QMP block operation (but those are error prone already anyway) _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
