public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Severen Redwood via pve-devel <pve-devel@lists.proxmox.com>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
	 Alexandre Derumier <alexandre.derumier@groupe-cyllene.com>
Cc: Severen Redwood <severen.redwood@sitehost.co.nz>
Subject: Re: [pve-devel] [PATCH manager 1/2] close #4369: api: optionally only suggest unique IDs
Date: Mon, 30 Sep 2024 14:58:51 +1300	[thread overview]
Message-ID: <mailman.133.1727661586.332.pve-devel@lists.proxmox.com> (raw)
In-Reply-To: <mailman.127.1727618619.332.pve-devel@lists.proxmox.com>

[-- Attachment #1: Type: message/rfc822, Size: 4690 bytes --]

From: Severen Redwood <severen.redwood@sitehost.co.nz>
To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>,  Alexandre Derumier <alexandre.derumier@groupe-cyllene.com>
Subject: Re: [pve-devel] [PATCH manager 1/2] close #4369: api: optionally only suggest unique IDs
Date: Mon, 30 Sep 2024 14:58:51 +1300
Message-ID: <ce6ov3znxweopubjnsw35m5aiboohi2r5yza76brljruxyhbmx@wbnvnhtmvq4v>

On Sun, Sep 29, 2024 at 01:47:31PM GMT, DERUMIER, Alexandre via pve-devel wrote:
> Couldn't we simply move the deleted vm config file
> to a trash/tombstone directory ?
> 
> /etc/pve/.deleted/<vmid>.conf ?
> 
> 
> (I could be great to be able to mass delete vms in // without having a
> big lock on a file)

This is an interesting idea, though I think creating an empty file is
probably better than moving the config as that would only store
information that will never be needed again. Needing to acquire a lock
on the list when deleting multiple VMs may be a bottleneck, but I'm not
entirely convinced it would actually be a problem in practice. How many
VMs do you expect to be deleting all at once? And how often?

This approach would also use more storage as you now have the overhead
of FS metadata for every single ID you have marked as used.

Dietmar, what do you think is the best option here? I'm personally
leaning towards using the list with your run-length encoding suggestion,
but I'm open to implementing Alexandre's idea if you think it's worth
it.


[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
pve-devel mailing list
pve-devel@lists.proxmox.com
https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel

  reply	other threads:[~2024-09-30  1:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20240926135516.117065-1-severen.redwood@sitehost.co.nz>
2024-09-26 13:52 ` Severen Redwood via pve-devel
2024-09-26 15:34   ` Dietmar Maurer
2024-09-29 13:47     ` DERUMIER, Alexandre via pve-devel
2024-09-30  1:58       ` Severen Redwood via pve-devel [this message]
     [not found]       ` <ce6ov3znxweopubjnsw35m5aiboohi2r5yza76brljruxyhbmx@wbnvnhtmvq4v>
2024-09-30  7:50         ` Dietmar Maurer
2024-09-30  8:06           ` DERUMIER, Alexandre via pve-devel
2024-09-26 13:52 ` [pve-devel] [PATCH manager 2/2] close #4369: ui: add datacenter option for unique VM/CT IDs Severen Redwood via pve-devel
2024-09-26 13:52 ` [pve-devel] [PATCH container] api: record CT ID as used after a container is destroyed Severen Redwood via pve-devel
2024-09-26 13:52 ` [pve-devel] [PATCH qemu-server] api: record VM ID as used after a virtual machine " Severen Redwood via pve-devel
2024-09-26 13:52 ` [pve-devel] [PATCH cluster 1/2] cluster files: add used_vmids.list Severen Redwood via pve-devel
2024-09-26 13:52 ` [pve-devel] [PATCH cluster 2/2] datacenter config: add unique-next-id to schema Severen Redwood via pve-devel
     [not found] ` <20240926135516.117065-4-severen.redwood@sitehost.co.nz>
2024-09-26 17:48   ` [pve-devel] [PATCH container] api: record CT ID as used after a container is destroyed Thomas Lamprecht
2024-09-30  0:24     ` Severen Redwood via pve-devel
     [not found] ` <20240926135516.117065-5-severen.redwood@sitehost.co.nz>
2024-09-26 17:53   ` [pve-devel] [PATCH qemu-server] api: record VM ID as used after a virtual machine " Thomas Lamprecht

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=mailman.133.1727661586.332.pve-devel@lists.proxmox.com \
    --to=pve-devel@lists.proxmox.com \
    --cc=alexandre.derumier@groupe-cyllene.com \
    --cc=severen.redwood@sitehost.co.nz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal