From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <f.ebner@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 C72BB621C7
for <pve-devel@lists.proxmox.com>; Thu, 20 Aug 2020 11:22:40 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
by firstgate.proxmox.com (Proxmox) with ESMTP id BEE852BF86
for <pve-devel@lists.proxmox.com>; Thu, 20 Aug 2020 11:22:10 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
[212.186.127.180])
(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 id 201D82BF79
for <pve-devel@lists.proxmox.com>; Thu, 20 Aug 2020 11:22:10 +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 DCDBA4472E
for <pve-devel@lists.proxmox.com>; Thu, 20 Aug 2020 11:22:09 +0200 (CEST)
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
Proxmox VE development discussion <pve-devel@lists.proxmox.com>
References: <20200812100127.29722-1-f.ebner@proxmox.com>
<20200812100127.29722-3-f.ebner@proxmox.com>
<e858283b-e216-a6e6-bdfb-846f977d745b@proxmox.com>
From: Fabian Ebner <f.ebner@proxmox.com>
Message-ID: <aa9eca03-4ed3-a0d5-152a-8b594824668d@proxmox.com>
Date: Thu, 20 Aug 2020 11:22:09 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <e858283b-e216-a6e6-bdfb-846f977d745b@proxmox.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-SPAM-LEVEL: Spam detection results: 0
AWL 0.670 Adjusted score from AWL reputation of From: address
KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
NICE_REPLY_A -1.361 Looks like a legit reply (A)
RCVD_IN_DNSWL_MED -2.3 Sender listed at https://www.dnswl.org/,
medium trust
SPF_HELO_NONE 0.001 SPF: HELO does not publish an 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. [qemuserver.pm]
Subject: Re: [pve-devel] [PATCH/RFC v2 qemu-server 3/3] restore_vma_archive:
remove timeout for reading the device map
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: Thu, 20 Aug 2020 09:22:40 -0000
Am 20.08.20 um 10:53 schrieb Thomas Lamprecht:
> On 12.08.20 12:01, Fabian Ebner wrote:
>> If there is no serious problem, it shouldn't be possible to run into
>> this timeout anyways. It's just (extracting and) reading the header of
>> the (compressed) vma file. And if there is a serious problem, then the
>> commands will most likely fail for a different reason, e.g. unable to open,
>> corrupt vma, etc.
>>
>> Signed-off-by: Fabian Ebner <f.ebner@proxmox.com>
>> ---
>>
>> New in v2
>>
>> Hope I'm not missing anything important.
>
> the process doing the read can hang on IO for a long time, that can be pretty normal,
> especially on network attached storage and some IO load.
> Not saying that this isn't OK at all, but your commit message suggests misleadingly
> that this would either be very short or an immediate error, which isn't exactly true.
>
True, so this timeout can trigger in such cases. The question is if we
want to die after 5 seconds in that case (current behavior) or if we
just give it as much time as it needs and let the user cancel if
something hangs completely.
>>
>> PVE/QemuServer.pm | 8 --------
>> 1 file changed, 8 deletions(-)
>>
>> diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
>> index 794819b..342114d 100644
>> --- a/PVE/QemuServer.pm
>> +++ b/PVE/QemuServer.pm
>> @@ -6162,8 +6162,6 @@ sub restore_vma_archive {
>>
>> $add_pipe->(['vma', 'extract', '-v', '-r', $mapfifo, $readfrom, $tmpdir]);
>>
>> - my $timeout = 5;
>> -
>> my $devinfo = {};
>>
>> my $rpcenv = PVE::RPCEnvironment::get();
>> @@ -6260,9 +6258,6 @@ sub restore_vma_archive {
>> local $SIG{QUIT} =
>> local $SIG{HUP} =
>> local $SIG{PIPE} = sub { die "interrupted by signal\n"; };
>> - local $SIG{ALRM} = sub { die "got timeout reading device map\n"; };
>> -
>> - alarm($timeout);
>>
>> my $parser = sub {
>> my $line = shift;
>> @@ -6273,7 +6268,6 @@ sub restore_vma_archive {
>> my ($dev_id, $size, $devname) = ($1, $2, $3);
>> $devinfo->{$devname} = { size => $size, dev_id => $dev_id };
>> } elsif ($line =~ m/^CTIME: /) {
>> - alarm(0);
>> &$print_devmap();
>> print $fifofh "done\n";
>> close($fifofh);
>> @@ -6285,8 +6279,6 @@ sub restore_vma_archive {
>> };
>> my $err = $@;
>>
>> - alarm(0);
>> -
>> $restore_deactivate_volumes->($cfg, $devinfo);
>>
>> unlink $mapfifo;
>>
>