On 01.07.20 14:43, Fabian Grünbichler wrote: > On July 1, 2020 2:05 pm, Thomas Lamprecht wrote: >> On 01.07.20 09:11, Fabian Grünbichler wrote: >>> - we can actually just put the new mpX into the pending queue, and >>> remove the entry from the pending deletion queue? (it's hotplugging >>> that is the problem, not queuing the pending change) >> >> Even if we could I'm not sure I want to be able to add a new mpX as pending >> if the old is still pending its deletion. But, tbh, I did not looked at >> details >> so I may missing something.. > > well, the sequence is > > - delete mp0 (queued) > - set a new mp0 (queued) > > just like a general > > - delete foo (queued) > - set foo (queued) > > where the set removes the queued deletion. in the case of mp, applying > that pending change should then add the old volume ID as unused, but > that IMHO does not change the semantics of '(queuing a) set overrides > earlier queued delete'.
IMO the set mpX isn't your general option setting, and I'd just not allow re-setting it with a delete still pending, to dangerous IMO. Maybe better make it clear for the user that they either need to apply the pending change (e.g., CT reboot), revert it or just use another mpX id. > > but this is broken for regular hotplug without deletion as well, setting > mpX with a new volume ID if the slot is already used does not queue it > as pending change, but > - mounts the new volume ID in addition to the old one > - adds the old volume ID as unused, even though it is still mounted in > the container gosh.. yeah that needs to fail too. > > so this is broken in more ways than just what I initially found.. > _______________________________________________ pve-devel mailing list pve-devel@pve.proxmox.com https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
