public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: Fiona Ebner <f.ebner@proxmox.com>
To: Dominik Csapak <d.csapak@proxmox.com>,
	Proxmox VE development discussion <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] [PATCH qemu-server 1/3] fix #2816: restore: remove timeout when allocating disks
Date: Mon, 25 Sep 2023 10:46:08 +0200	[thread overview]
Message-ID: <1d6ae212-9b16-ab4d-e025-07664c35d06a@proxmox.com> (raw)
In-Reply-To: <6ff59a25-0401-41c4-8352-379bc0bafeb3@proxmox.com>

Am 20.09.23 um 13:23 schrieb Dominik Csapak:
> comment inline:

Feel free to cut out irrelevant parts in the reply ;)

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

>> +        alarm($oldtimeout || 0);
>> +        $oldtimeout = undef;
> 
> 
> this part looks wrong to me, because AFAIU you want to disable the timeout
> (by canceling the alarm), but what you do here is to set it to $oldtimeout
> if that was set before?
> 
> i guess what we want to do here is:
> 
> ----
> alarm(0);
> <... do stuff ...>
> alarm($oldtimeout || 0);
> $oldtimeout = undef;
> ----
> 
> ?

Hmm, I see what you mean. But I'd argue that it's unexpected to disable
the outer timeout for the full duration of the allocation from a
caller's perspective.

sub in_a_hurry {
    alarm(120); # outer/old timeout
    restore_vma_archive(...);
}

With the code before the patch, it could take up to 5 + 600 + 120
seconds to hit the outer timeout, with your suggestion up to 5 +
potentially unlimited + 120 seconds, with patched code up to 5 + 120
seconds. Since there currently are no callers setting an outer timeout,
the patch doesn't make the situation worse.

We could even make the calculation more complicated and have the timeout
always be hit within 120 seconds in the example above, but not sure if
worth it.

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.




  parent reply	other threads:[~2023-09-25  8:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-12  9:16 Fiona Ebner
2023-09-12  9:16 ` [pve-devel] [PATCH qemu-server 2/3] restore vma: add comment describing timeout Fiona Ebner
2023-09-12  9:16 ` [pve-devel] [PATCH qemu-server 3/3] restore vma: inline one timeout variable and move other closer to usage Fiona Ebner
2023-09-20 11:23 ` [pve-devel] [PATCH qemu-server 1/3] fix #2816: restore: remove timeout when allocating disks Dominik Csapak
2023-09-20 11:28   ` Dominik Csapak
2023-09-25  8:46   ` Fiona Ebner [this message]
2023-09-25  8:57     ` Dominik Csapak
2023-09-25 10:30       ` Fiona Ebner
2023-09-25 11:25         ` Dominik Csapak
2023-11-17  8:49 ` [pve-devel] applied-series: " 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=1d6ae212-9b16-ab4d-e025-07664c35d06a@proxmox.com \
    --to=f.ebner@proxmox.com \
    --cc=d.csapak@proxmox.com \
    --cc=pve-devel@lists.proxmox.com \
    /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