From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) by lore.proxmox.com (Postfix) with ESMTPS id 9FD951FF165 for ; Thu, 17 Jul 2025 16:48:45 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id DD8803E1A9; Thu, 17 Jul 2025 16:49:50 +0200 (CEST) Date: Thu, 17 Jul 2025 15:49:05 +0100 To: Proxmox VE development discussion References: <20250709162202.2952597-1-alexandre.derumier@groupe-cyllene.com> <45f99f85-19e2-497e-96b4-c22b9a33de6a@proxmox.com> In-Reply-To: MIME-Version: 1.0 Message-ID: List-Id: Proxmox VE development discussion List-Post: From: Tiago Sousa via pve-devel Precedence: list Cc: Tiago Sousa X-Mailman-Version: 2.1.29 X-BeenThere: pve-devel@lists.proxmox.com List-Subscribe: , List-Unsubscribe: , List-Archive: Reply-To: Proxmox VE development discussion List-Help: Subject: Re: [pve-devel] [PATCH-SERIES v8 pve-storage/qemu-server] add external qcow2 snapshot support Content-Type: multipart/mixed; boundary="===============4756786631808941702==" Errors-To: pve-devel-bounces@lists.proxmox.com Sender: "pve-devel" --===============4756786631808941702== Content-Type: message/rfc822 Content-Disposition: inline Return-Path: X-Original-To: pve-devel@lists.proxmox.com Delivered-To: pve-devel@lists.proxmox.com Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.proxmox.com (Postfix) with ESMTPS id 694A7CA201 for ; Thu, 17 Jul 2025 16:49:49 +0200 (CEST) Received: from firstgate.proxmox.com (localhost [127.0.0.1]) by firstgate.proxmox.com (Proxmox) with ESMTP id 47F043E0FA for ; Thu, 17 Jul 2025 16:49:19 +0200 (CEST) Received: from eurotux.com (mail.eurotux.com [185.98.249.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by firstgate.proxmox.com (Proxmox) with ESMTPS for ; Thu, 17 Jul 2025 16:49:16 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by eurotux.com (Postfix) with ESMTP id 7B8E130CA7CB; Thu, 17 Jul 2025 15:49:07 +0100 (WEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eurotux.com; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:content-language:references:subject:subject :user-agent:mime-version:date:date:message-id; s=default; t= 1752763746; x=1754578147; bh=j8PmBxdpeUodfm+0VZvcs4xM0rcrX65eJgb GHUxdW6E=; b=kcPWRj7dQU6hdzVAornoY7vM+72wXBtl/ATU6gXXzuCQv5XalRC EzC5QUcJN4XbWCyX4htq6OduTuFgj3O1wtEuky3vjhfrfM5nc0sT/9z4XWfgPFZs cfg77bi6/zW7pQeeg+1vuOBaXoxcDNTYIvZBVTkMVYvY3CE5gdfe7jqHd/Ro1COd sQec9wlbnzh3yYQkbaOAdAw9oBDqzwH/MLFNMIHKG3XlQVmU5iZTqhvwAojCbcKp uNUKZPh981FZCjudgbaaHbnOIjiCRY7Ux3b+7oZAjxAJLY3RwugtX0VjowrCjj05 QSahtSAR6GObSCSVQ1MBfGcsmDaV/l1t0+g== X-Virus-Scanned: amavisd-new at mail.prd.eurotux.pt Received: from eurotux.com ([127.0.0.1]) by localhost (mail.prd.eurotux.pt [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id cQZafrz-VQXZ; Thu, 17 Jul 2025 15:49:06 +0100 (WEST) Received: from [192.168.1.213] (unknown [161.230.225.89]) (Authenticated sender: joao.sousa@eurotux.com) by eurotux.com (Postfix) with ESMTPSA id 9A6E130CC01E; Thu, 17 Jul 2025 15:49:06 +0100 (WEST) Message-ID: <1fddff1a-b806-475a-ac75-1dd0107d1013@eurotux.com> Date: Thu, 17 Jul 2025 15:49:05 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [pve-devel] [PATCH-SERIES v8 pve-storage/qemu-server] add external qcow2 snapshot support To: Proxmox VE development discussion References: <20250709162202.2952597-1-alexandre.derumier@groupe-cyllene.com> <45f99f85-19e2-497e-96b4-c22b9a33de6a@proxmox.com> Content-Language: en-US From: Tiago Sousa In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-SPAM-LEVEL: Spam detection results: 0 AWL -0.153 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain DMARC_PASS -0.1 DMARC pass policy POISEN_SPAM_PILL 0.1 Meta: its spam POISEN_SPAM_PILL_1 0.1 random spam to be learned in bayes POISEN_SPAM_PILL_3 0.1 random spam to be learned in bayes RCVD_IN_MSPIKE_H2 0.001 Average reputation (+2) RCVD_IN_VALIDITY_CERTIFIED_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_RPBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. RCVD_IN_VALIDITY_SAFE_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to Validity was blocked. See https://knowledge.validity.com/hc/en-us/articles/20961730681243 for more information. SPF_HELO_PASS -0.001 SPF: HELO matches SPF record SPF_PASS -0.001 SPF: sender matches SPF record URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [eurotux.com,proxmox.com] Hi, I'm starting to develop the thin provisioning feature to integrate with the new snapshot feature for LVM. The architecture I'm following is very similar to the one Alexandre mentioned here https://lore.proxmox.com/pve-devel/mailman.380.1750053104.395.pve-devel@lists.proxmox.com/ However I have some questions: 1. When qmeventd receives the BLOCK_WRITE_THRESHOLD event, should the extend request (writing the nodename to the extend queue) be handled directly in C, or would it be preferable to do it via an API call such as PUT /nodes/{node}/qemu/{vmid}/extend_request, passing the nodename as a parameter? 2. If we use a local daemon for each node how is it decided which node will preform the extend operation? Another option is to use a centralized daemon (maybe on the quorum master) that performs every extend. 3. Is there any specific reason for the event only be triggered at 50% of last chunk, in your implementation? I was thinking of implementing it with 10% of the current provisioned space to be safe. Any options on this? In terms of locking I'm planning to use the cfs_lock_file to write to the extend queue and cfs_lock_storage to perform the extend on the target disk. --===============4756786631808941702== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ pve-devel mailing list pve-devel@lists.proxmox.com https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel --===============4756786631808941702==--