[pve-devel] [PATCH container] fix #2820: block adding new volume with same id if it's pending delete

Thomas Lamprecht t.lamprecht at proxmox.com
Wed Jul 1 14:50:06 CEST 2020


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..
> 





More information about the pve-devel mailing list