From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <d.tschlatscher@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 1F33092005;
 Mon, 10 Oct 2022 13:41:25 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
 by firstgate.proxmox.com (Proxmox) with ESMTP id EFE32356D;
 Mon, 10 Oct 2022 13:40:54 +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;
 Mon, 10 Oct 2022 13:40:54 +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 D00AC44224;
 Mon, 10 Oct 2022 13:40:53 +0200 (CEST)
Message-ID: <09162367-74c0-a233-b913-a1b0e9477ef7@proxmox.com>
Date: Mon, 10 Oct 2022 13:40:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
 Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
 pbs-devel@lists.proxmox.com, pmg-devel@lists.proxmox.com
References: <20220907085633.89113-1-d.tschlatscher@proxmox.com>
 <20220907085633.89113-5-d.tschlatscher@proxmox.com>
 <a61f3b86-6591-2d72-fd78-45f247fdd71e@proxmox.com>
Content-Language: en-US
From: Daniel Tschlatscher <d.tschlatscher@proxmox.com>
In-Reply-To: <a61f3b86-6591-2d72-fd78-45f247fdd71e@proxmox.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-SPAM-LEVEL: Spam detection results:  0
 AWL 1.860 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
 NICE_REPLY_A           -3.934 Looks like a legit reply (A)
 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 manager v2 4/7] revised task log API call
 for PVE
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, 10 Oct 2022 11:41:25 -0000

Thanks for the review!

On 10/5/22 14:30, Thomas Lamprecht wrote:
> Am 07/09/2022 um 10:56 schrieb Daniel Tschlatscher:
>> The API call for fetching a tasklog with limit=0 now returns the whole
>> log as a file stream rather than reading all lines in memory and then
>> transfering them in JSON format. The behaviour when the url parameter
>> limit is undefined or not 0 is the same as before, in accordance
>> with the API specification.
>>
>> Signed-off-by: Daniel Tschlatscher <d.tschlatscher@proxmox.com>
>> ---
>>  PVE/API2/Tasks.pm | 13 ++++++++++---
>>  1 file changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/PVE/API2/Tasks.pm b/PVE/API2/Tasks.pm
>> index 9cd1e56b..88762f2f 100644
>> --- a/PVE/API2/Tasks.pm
>> +++ b/PVE/API2/Tasks.pm
>> @@ -5,6 +5,7 @@ use warnings;
>>  use POSIX;
>>  use IO::File;
>>  use File::ReadBackwards;
>> +use File::stat;
>>  use PVE::Tools;
>>  use PVE::SafeSyslog;
>>  use PVE::RESTHandler;
>> @@ -387,11 +388,17 @@ __PACKAGE__->register_method({
>>  	    $rpcenv->check($user, "/nodes/$node", [ 'Sys.Audit' ]);
>>  	}
>>  
>> -	my ($count, $lines) = PVE::Tools::dump_logfile($filename, $start, $limit);
>> +	if ($limit == 0) {
>> +	    # TCP Max Transfer Unit size is 1500, compression for lower numbers has no effect
> 
> What do you mean here? The MTU of the Ethernet data layer? As that would make
> more sense, there the most common (but not guaranteed) MTU is indeed 1500. TCP
> can send more data per packet just fine if the MTU of the underlying (ethernet)
> network is bigger, like the often used MTU of 9000 in LANs.
> 
> Note also that the actual file size that can be transmitted in one packet would
> need to factor in IP, TCP and HTTP overhead though.
> 
> For IPv4 you'd use 16 byte for the IP and 24 bytes for the TCP part of the
> packet, so it'd be 1460 bytes, the HTTP header isn't as deterministic and for
> IPv6 it's more overhead eating away the possible payload size.
> 
> That alls said, we could still use the 1500 as cut-off, nothing inherently against
> that per se, but the comment should not refer to the confusing TCP MTU and mention
> that the boundary depends.
> 
> For finding a cutoff we could look at file distribution size of task log in existing
> (non-test) instances, e.g. with:
> 
> find /var/log/pve/tasks/ -mindepth 2 -type f -print0 | xargs -0 ls -l | awk '{size[int(log($5)/log(2))]++}END{for (i in size) printf("%10d %3d\n", 2^i, size[i])}' | sort -n
> 
> 
> For three relatively active and long lived host this gives:
>     Size       A      B     C
>                        1
>          8    567    669   121
>         16      3     28
>         32     40    106     6
>         64     60     23
>        128     63     28
>        256     22     25     8
>        512      8     12     4
>       1024      8     32    40
>       2048      2     12    17
>       4096      5      1
>       8192     14      1   695
>      16384     18            1
>      32768     24
> 
> 
> I then compressed all files with gzip and reran:
> 
>         32   1
>         64 596
>        128 154
>        256  14
>        512  13
>       1024   4
>       2048  14
>       4096  18
>       8192  24
> 
>         32   1
>         64 784
>        128  74
>        256  38
>        512  41
>       1024   2
>       4096   1
>       8192   1
> 
> So, I'd just use 1024 as cut-off, that isn't bound to such dynamic limits like TCP
> actual payload per single package size, but will still fit in most and even captures
> most of the previously selected files in practice anyway. Also gzip is normally
> able to compress text quite well so doing that with log (i.e., not random data) text
> files bigger than 1KiB will almost never over the uncompressed limit. If you rather
> like a higher size you can also use 2 or 4 KiB, both fine too IMO.
> 

Sorry for the confusion, my train of thought here was that compression
would be most useful for connections over the internet. Of which the big
majority use an MTU size of 1500, as far as I understand.
Thank you for the inquisitive input here, I think 1024 might be the most
useful number to use for this then.

>> +	    my $use_compression = stat($filename)->size > 1500;
> 
> should be able to use: -s $filename > X
> 
>> +	    return PVE::Tools::stream_file($filename, $param->{upid}, $use_compression);
> 
> IMO the helper isn't to useful, I'd just do this inline.
> 

The stream_file helper?
It does save about 20 lines of very redundant code in both pmg and pve
each and should make it easy to implement potential other download
calls. Though, that hinges on the question on how likely it is that
there will be such a need.

Or are you talking about something else here?

>> +	} else {
> 
> no else required, other branch returns.
> 
>> +	    my ($count, $lines) = PVE::Tools::dump_logfile($filename, $start, $limit);
>>  
>> -	$rpcenv->set_result_attrib('total', $count);
>> +	    $rpcenv->set_result_attrib('total', $count);
>>  
>> -	return $lines;
>> +	    return $lines;
>> +	}
>>      }});
>>  
>>  
> 




From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <d.tschlatscher@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 1F33092005;
 Mon, 10 Oct 2022 13:41:25 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
 by firstgate.proxmox.com (Proxmox) with ESMTP id EFE32356D;
 Mon, 10 Oct 2022 13:40:54 +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;
 Mon, 10 Oct 2022 13:40:54 +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 D00AC44224;
 Mon, 10 Oct 2022 13:40:53 +0200 (CEST)
Message-ID: <09162367-74c0-a233-b913-a1b0e9477ef7@proxmox.com>
Date: Mon, 10 Oct 2022 13:40:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
 Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
 pbs-devel@lists.proxmox.com, pmg-devel@lists.proxmox.com
References: <20220907085633.89113-1-d.tschlatscher@proxmox.com>
 <20220907085633.89113-5-d.tschlatscher@proxmox.com>
 <a61f3b86-6591-2d72-fd78-45f247fdd71e@proxmox.com>
Content-Language: en-US
From: Daniel Tschlatscher <d.tschlatscher@proxmox.com>
In-Reply-To: <a61f3b86-6591-2d72-fd78-45f247fdd71e@proxmox.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-SPAM-LEVEL: Spam detection results:  0
 AWL 1.860 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
 NICE_REPLY_A           -3.934 Looks like a legit reply (A)
 SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
Subject: Re: [pbs-devel] [pve-devel] [PATCH manager v2 4/7] revised task log
 API call for PVE
X-BeenThere: pbs-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox Backup Server development discussion
 <pbs-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pbs-devel>, 
 <mailto:pbs-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pbs-devel/>
List-Post: <mailto:pbs-devel@lists.proxmox.com>
List-Help: <mailto:pbs-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pbs-devel>, 
 <mailto:pbs-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Mon, 10 Oct 2022 11:41:25 -0000

Thanks for the review!

On 10/5/22 14:30, Thomas Lamprecht wrote:
> Am 07/09/2022 um 10:56 schrieb Daniel Tschlatscher:
>> The API call for fetching a tasklog with limit=0 now returns the whole
>> log as a file stream rather than reading all lines in memory and then
>> transfering them in JSON format. The behaviour when the url parameter
>> limit is undefined or not 0 is the same as before, in accordance
>> with the API specification.
>>
>> Signed-off-by: Daniel Tschlatscher <d.tschlatscher@proxmox.com>
>> ---
>>  PVE/API2/Tasks.pm | 13 ++++++++++---
>>  1 file changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/PVE/API2/Tasks.pm b/PVE/API2/Tasks.pm
>> index 9cd1e56b..88762f2f 100644
>> --- a/PVE/API2/Tasks.pm
>> +++ b/PVE/API2/Tasks.pm
>> @@ -5,6 +5,7 @@ use warnings;
>>  use POSIX;
>>  use IO::File;
>>  use File::ReadBackwards;
>> +use File::stat;
>>  use PVE::Tools;
>>  use PVE::SafeSyslog;
>>  use PVE::RESTHandler;
>> @@ -387,11 +388,17 @@ __PACKAGE__->register_method({
>>  	    $rpcenv->check($user, "/nodes/$node", [ 'Sys.Audit' ]);
>>  	}
>>  
>> -	my ($count, $lines) = PVE::Tools::dump_logfile($filename, $start, $limit);
>> +	if ($limit == 0) {
>> +	    # TCP Max Transfer Unit size is 1500, compression for lower numbers has no effect
> 
> What do you mean here? The MTU of the Ethernet data layer? As that would make
> more sense, there the most common (but not guaranteed) MTU is indeed 1500. TCP
> can send more data per packet just fine if the MTU of the underlying (ethernet)
> network is bigger, like the often used MTU of 9000 in LANs.
> 
> Note also that the actual file size that can be transmitted in one packet would
> need to factor in IP, TCP and HTTP overhead though.
> 
> For IPv4 you'd use 16 byte for the IP and 24 bytes for the TCP part of the
> packet, so it'd be 1460 bytes, the HTTP header isn't as deterministic and for
> IPv6 it's more overhead eating away the possible payload size.
> 
> That alls said, we could still use the 1500 as cut-off, nothing inherently against
> that per se, but the comment should not refer to the confusing TCP MTU and mention
> that the boundary depends.
> 
> For finding a cutoff we could look at file distribution size of task log in existing
> (non-test) instances, e.g. with:
> 
> find /var/log/pve/tasks/ -mindepth 2 -type f -print0 | xargs -0 ls -l | awk '{size[int(log($5)/log(2))]++}END{for (i in size) printf("%10d %3d\n", 2^i, size[i])}' | sort -n
> 
> 
> For three relatively active and long lived host this gives:
>     Size       A      B     C
>                        1
>          8    567    669   121
>         16      3     28
>         32     40    106     6
>         64     60     23
>        128     63     28
>        256     22     25     8
>        512      8     12     4
>       1024      8     32    40
>       2048      2     12    17
>       4096      5      1
>       8192     14      1   695
>      16384     18            1
>      32768     24
> 
> 
> I then compressed all files with gzip and reran:
> 
>         32   1
>         64 596
>        128 154
>        256  14
>        512  13
>       1024   4
>       2048  14
>       4096  18
>       8192  24
> 
>         32   1
>         64 784
>        128  74
>        256  38
>        512  41
>       1024   2
>       4096   1
>       8192   1
> 
> So, I'd just use 1024 as cut-off, that isn't bound to such dynamic limits like TCP
> actual payload per single package size, but will still fit in most and even captures
> most of the previously selected files in practice anyway. Also gzip is normally
> able to compress text quite well so doing that with log (i.e., not random data) text
> files bigger than 1KiB will almost never over the uncompressed limit. If you rather
> like a higher size you can also use 2 or 4 KiB, both fine too IMO.
> 

Sorry for the confusion, my train of thought here was that compression
would be most useful for connections over the internet. Of which the big
majority use an MTU size of 1500, as far as I understand.
Thank you for the inquisitive input here, I think 1024 might be the most
useful number to use for this then.

>> +	    my $use_compression = stat($filename)->size > 1500;
> 
> should be able to use: -s $filename > X
> 
>> +	    return PVE::Tools::stream_file($filename, $param->{upid}, $use_compression);
> 
> IMO the helper isn't to useful, I'd just do this inline.
> 

The stream_file helper?
It does save about 20 lines of very redundant code in both pmg and pve
each and should make it easy to implement potential other download
calls. Though, that hinges on the question on how likely it is that
there will be such a need.

Or are you talking about something else here?

>> +	} else {
> 
> no else required, other branch returns.
> 
>> +	    my ($count, $lines) = PVE::Tools::dump_logfile($filename, $start, $limit);
>>  
>> -	$rpcenv->set_result_attrib('total', $count);
>> +	    $rpcenv->set_result_attrib('total', $count);
>>  
>> -	return $lines;
>> +	    return $lines;
>> +	}
>>      }});
>>  
>>  
> 




From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <d.tschlatscher@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 1F33092005;
 Mon, 10 Oct 2022 13:41:25 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
 by firstgate.proxmox.com (Proxmox) with ESMTP id EFE32356D;
 Mon, 10 Oct 2022 13:40:54 +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;
 Mon, 10 Oct 2022 13:40:54 +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 D00AC44224;
 Mon, 10 Oct 2022 13:40:53 +0200 (CEST)
Message-ID: <09162367-74c0-a233-b913-a1b0e9477ef7@proxmox.com>
Date: Mon, 10 Oct 2022 13:40:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.3.0
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
 Proxmox VE development discussion <pve-devel@lists.proxmox.com>,
 pbs-devel@lists.proxmox.com, pmg-devel@lists.proxmox.com
References: <20220907085633.89113-1-d.tschlatscher@proxmox.com>
 <20220907085633.89113-5-d.tschlatscher@proxmox.com>
 <a61f3b86-6591-2d72-fd78-45f247fdd71e@proxmox.com>
Content-Language: en-US
From: Daniel Tschlatscher <d.tschlatscher@proxmox.com>
In-Reply-To: <a61f3b86-6591-2d72-fd78-45f247fdd71e@proxmox.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-SPAM-LEVEL: Spam detection results:  0
 AWL 1.860 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
 NICE_REPLY_A           -3.934 Looks like a legit reply (A)
 SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
Subject: Re: [pmg-devel] [pve-devel] [PATCH manager v2 4/7] revised task log
 API call for PVE
X-BeenThere: pmg-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox Mail Gateway development discussion
 <pmg-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pmg-devel>, 
 <mailto:pmg-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pmg-devel/>
List-Post: <mailto:pmg-devel@lists.proxmox.com>
List-Help: <mailto:pmg-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pmg-devel>, 
 <mailto:pmg-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Mon, 10 Oct 2022 11:41:25 -0000

Thanks for the review!

On 10/5/22 14:30, Thomas Lamprecht wrote:
> Am 07/09/2022 um 10:56 schrieb Daniel Tschlatscher:
>> The API call for fetching a tasklog with limit=0 now returns the whole
>> log as a file stream rather than reading all lines in memory and then
>> transfering them in JSON format. The behaviour when the url parameter
>> limit is undefined or not 0 is the same as before, in accordance
>> with the API specification.
>>
>> Signed-off-by: Daniel Tschlatscher <d.tschlatscher@proxmox.com>
>> ---
>>  PVE/API2/Tasks.pm | 13 ++++++++++---
>>  1 file changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/PVE/API2/Tasks.pm b/PVE/API2/Tasks.pm
>> index 9cd1e56b..88762f2f 100644
>> --- a/PVE/API2/Tasks.pm
>> +++ b/PVE/API2/Tasks.pm
>> @@ -5,6 +5,7 @@ use warnings;
>>  use POSIX;
>>  use IO::File;
>>  use File::ReadBackwards;
>> +use File::stat;
>>  use PVE::Tools;
>>  use PVE::SafeSyslog;
>>  use PVE::RESTHandler;
>> @@ -387,11 +388,17 @@ __PACKAGE__->register_method({
>>  	    $rpcenv->check($user, "/nodes/$node", [ 'Sys.Audit' ]);
>>  	}
>>  
>> -	my ($count, $lines) = PVE::Tools::dump_logfile($filename, $start, $limit);
>> +	if ($limit == 0) {
>> +	    # TCP Max Transfer Unit size is 1500, compression for lower numbers has no effect
> 
> What do you mean here? The MTU of the Ethernet data layer? As that would make
> more sense, there the most common (but not guaranteed) MTU is indeed 1500. TCP
> can send more data per packet just fine if the MTU of the underlying (ethernet)
> network is bigger, like the often used MTU of 9000 in LANs.
> 
> Note also that the actual file size that can be transmitted in one packet would
> need to factor in IP, TCP and HTTP overhead though.
> 
> For IPv4 you'd use 16 byte for the IP and 24 bytes for the TCP part of the
> packet, so it'd be 1460 bytes, the HTTP header isn't as deterministic and for
> IPv6 it's more overhead eating away the possible payload size.
> 
> That alls said, we could still use the 1500 as cut-off, nothing inherently against
> that per se, but the comment should not refer to the confusing TCP MTU and mention
> that the boundary depends.
> 
> For finding a cutoff we could look at file distribution size of task log in existing
> (non-test) instances, e.g. with:
> 
> find /var/log/pve/tasks/ -mindepth 2 -type f -print0 | xargs -0 ls -l | awk '{size[int(log($5)/log(2))]++}END{for (i in size) printf("%10d %3d\n", 2^i, size[i])}' | sort -n
> 
> 
> For three relatively active and long lived host this gives:
>     Size       A      B     C
>                        1
>          8    567    669   121
>         16      3     28
>         32     40    106     6
>         64     60     23
>        128     63     28
>        256     22     25     8
>        512      8     12     4
>       1024      8     32    40
>       2048      2     12    17
>       4096      5      1
>       8192     14      1   695
>      16384     18            1
>      32768     24
> 
> 
> I then compressed all files with gzip and reran:
> 
>         32   1
>         64 596
>        128 154
>        256  14
>        512  13
>       1024   4
>       2048  14
>       4096  18
>       8192  24
> 
>         32   1
>         64 784
>        128  74
>        256  38
>        512  41
>       1024   2
>       4096   1
>       8192   1
> 
> So, I'd just use 1024 as cut-off, that isn't bound to such dynamic limits like TCP
> actual payload per single package size, but will still fit in most and even captures
> most of the previously selected files in practice anyway. Also gzip is normally
> able to compress text quite well so doing that with log (i.e., not random data) text
> files bigger than 1KiB will almost never over the uncompressed limit. If you rather
> like a higher size you can also use 2 or 4 KiB, both fine too IMO.
> 

Sorry for the confusion, my train of thought here was that compression
would be most useful for connections over the internet. Of which the big
majority use an MTU size of 1500, as far as I understand.
Thank you for the inquisitive input here, I think 1024 might be the most
useful number to use for this then.

>> +	    my $use_compression = stat($filename)->size > 1500;
> 
> should be able to use: -s $filename > X
> 
>> +	    return PVE::Tools::stream_file($filename, $param->{upid}, $use_compression);
> 
> IMO the helper isn't to useful, I'd just do this inline.
> 

The stream_file helper?
It does save about 20 lines of very redundant code in both pmg and pve
each and should make it easy to implement potential other download
calls. Though, that hinges on the question on how likely it is that
there will be such a need.

Or are you talking about something else here?

>> +	} else {
> 
> no else required, other branch returns.
> 
>> +	    my ($count, $lines) = PVE::Tools::dump_logfile($filename, $start, $limit);
>>  
>> -	$rpcenv->set_result_attrib('total', $count);
>> +	    $rpcenv->set_result_attrib('total', $count);
>>  
>> -	return $lines;
>> +	    return $lines;
>> +	}
>>      }});
>>  
>>  
>