From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <pve-devel-bounces@lists.proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [IPv6:2a01:7e0:0:424::9])
	by lore.proxmox.com (Postfix) with ESMTPS id A7CC01FF191
	for <inbox@lore.proxmox.com>; Mon,  2 Jun 2025 13:21:18 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
	by firstgate.proxmox.com (Proxmox) with ESMTP id 7EC0330D4C;
	Mon,  2 Jun 2025 13:21:34 +0200 (CEST)
Message-ID: <d30e61e0-942f-42dc-9e99-5609feb82e11@proxmox.com>
Date: Mon, 2 Jun 2025 13:21:30 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
 Proxmox VE development discussion <pve-devel@lists.proxmox.com>
References: <20250512124129.91914-1-f.ebner@proxmox.com>
 <98be9bd7-5a39-445e-9854-b9b9e44644f2@proxmox.com>
 <6d03512f-1fea-45c2-870e-5daf9bdf86e1@proxmox.com>
Content-Language: en-US
From: Fiona Ebner <f.ebner@proxmox.com>
In-Reply-To: <6d03512f-1fea-45c2-870e-5daf9bdf86e1@proxmox.com>
X-SPAM-LEVEL: Spam detection results:  0
 AWL -0.032 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DMARC_MISSING             0.1 Missing DMARC policy
 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
 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_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
Subject: Re: [pve-devel] [RFC common/manager/qemu-server 0/5] fix #3900:
 schema: support and prefer sizes with verbose suffixes {K, M, G, T}iB
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
Reply-To: Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: pve-devel-bounces@lists.proxmox.com
Sender: "pve-devel" <pve-devel-bounces@lists.proxmox.com>

Am 01.06.25 um 11:51 schrieb Thomas Lamprecht:
> Am 12.05.25 um 15:00 schrieb Fiona Ebner:
>> Am 12.05.25 um 14:41 schrieb Fiona Ebner:
>>> Maybe best is to wait for PVE 9 with this and do a parse+write for all
>>> guest configs (including their snapshots) in the pve8to9 script? The
>>> change also breaks backwards migration to a node that doesn't
>>> understand the new suffix.
>>
>> If we decide on that, I'll split the patch common 1/5 into two, since we
>> already need the parsing support in PVE 8 (or we couldn't rewrite in
>> pve8to9). And in PVE 9, we can switch to writing with the verbose
>> suffixes by default.
> 
> Saw this reply only later; yeah, please split this up and NACK form my
> side for such a rewrites in 8to9 checker script.

Ack, I'll send a v2 with only the parsing support (and the tangential
vzdump logging patch).

Regarding rewriting in pve8to9: I feel like it will be confusing to
users if there is a mix of suffixes in different guest configs. But
okay, I guess we can mention this as a known issue in the upgrade guide,
i.e. that the old suffixes for disks in guest configs meant powers of
1024 too (even if it's not an actual issue, but just ambiguity).

Alternatively, we could also add an UI patch to always display the new
suffix even if the config contains the old one?


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