From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <d.csapak@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))
(No client certificate requested)
by lists.proxmox.com (Postfix) with ESMTPS id 361B6E2BE
for <pve-devel@lists.proxmox.com>; Mon, 25 Sep 2023 13:25:06 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id 152081E9C0
for <pve-devel@lists.proxmox.com>; Mon, 25 Sep 2023 13:25:06 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
[94.136.29.106])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits))
(No client certificate requested)
by firstgate.proxmox.com (Proxmox) with ESMTPS
for <pve-devel@lists.proxmox.com>; Mon, 25 Sep 2023 13:25:03 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
by proxmox-new.maurer-it.com (Proxmox) with ESMTP id DD18648D34;
Mon, 25 Sep 2023 13:25:02 +0200 (CEST)
Message-ID: <e9ac7e57-0f7e-4a90-be27-9d4d6a2175ea@proxmox.com>
Date: Mon, 25 Sep 2023 13:25:02 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: Fiona Ebner <f.ebner@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
References: <20230912091617.26590-1-f.ebner@proxmox.com>
<6ff59a25-0401-41c4-8352-379bc0bafeb3@proxmox.com>
<1d6ae212-9b16-ab4d-e025-07664c35d06a@proxmox.com>
<c21a0808-16e6-4b18-aceb-94206a40f7ad@proxmox.com>
<5d552a06-26ac-f797-655b-72f88a7ab4d0@proxmox.com>
From: Dominik Csapak <d.csapak@proxmox.com>
In-Reply-To: <5d552a06-26ac-f797-655b-72f88a7ab4d0@proxmox.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-SPAM-LEVEL: Spam detection results: 0
AWL 0.011 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
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] [PATCH qemu-server 1/3] fix #2816: restore: remove
timeout when allocating disks
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>
X-List-Received-Date: Mon, 25 Sep 2023 11:25:06 -0000
On 9/25/23 12:30, Fiona Ebner wrote:
> Am 25.09.23 um 10:57 schrieb Dominik Csapak:
>> On 9/25/23 10:46, Fiona Ebner wrote:
>>> Am 20.09.23 um 13:23 schrieb Dominik Csapak:
>>>> On 9/12/23 11:16, Fiona Ebner wrote:
>>>>> @@ -7483,14 +7483,11 @@ sub restore_vma_archive {
>>>>> $devinfo->{$devname} = { size => $size, dev_id => $dev_id };
>>>>> } elsif ($line =~ m/^CTIME: /) {
>>>>> # we correctly received the vma config, so we can disable
>>>>> - # the timeout now for disk allocation (set to 10 minutes, so
>>>>> - # that we always timeout if something goes wrong)
>>>>> - alarm(600);
>>>>> + # the timeout now for disk allocation
>>>
>>> I would interpret this comment about disabling of the timeout to be
>>> talking about the short 5 second timeout for reading the config.
>>
>> ok, i interpreted it to be disabling *any* timeout to be able
>> to allocate the disks properly, and since there is only one global
>> timeout here, selectively disabling one seems strange?
>
> With that interpretation the code would be wrong of course.
>
>> i get what you mean, but maybe that would warrant a comment on the
>> function?
>> or maybe we should be able to clean up half allocated disks in there
>> in case the outer timeout triggers?
>
> AFAICS, my patch didn't change cleanup behavior and what you suggest
> already happens? The allocation is within an eval and we call
> restore_destroy_volumes() if there was an error during allocation (that
> also applies for a timeout error).
true, did not see that
>
>>
>> in any case, i'd find it good to improve the comment that speaks of
>> 'disabling the timeout' that it's meant to only disable the inner 5s one.
>>
>
> It can be seen from the code, but feel free to send a patch to improve it ;)
sure, i'll see if i can come up with better wording ;)
>
>>> AFAICS, we do similar "delay" of the outer timeout in e.g.
>>> run_with_timeout(), where it can also take up to $inner_timeout +
>>> $outer_timeout seconds to hit the outer timeout.
>>
>>
>> exactly, only our "inner" timeout here is undefined/unlimited because
>> disk allocation can take forever?
>>
>
> Why treat the operation as having unlimited inner timeout? What is the
> benefit? I'd expect our caller to have a good reason to set a timeout if
> it does, so why not try to honor it?
no sure, having the outer timeout as upper bound is fine for me too,
i was seemingly just confused by the two timeouts and the wording of the
comment
just to note, the function can still take an infinite time if
it hangs in the cleanup for example, but that's then expected i guess.