From: Dominik Csapak <d.csapak@proxmox.com>
To: Stoiko Ivanov <s.ivanov@proxmox.com>, pmg-devel@lists.proxmox.com
Subject: Re: [PATCH pmg-api] fix #7407: cluster: report: increase maximal filesize to 2M
Date: Mon, 16 Mar 2026 11:53:58 +0100 [thread overview]
Message-ID: <f14b8860-0835-4cdd-9143-027785d5e864@proxmox.com> (raw)
In-Reply-To: <20260313201321.18589-1-s.ivanov@proxmox.com>
just my thoughts:
if we're already increasing the limit here, and the file is
already a 1.4M, wouldn't it possibly make sense to increase
the allowed size a bit more? (e.g. 4/8M ?)
It's not an operation that happens too often (every few minutes)
so the additional memory usage should not matter much.
Though I guess this doesn't happen often either way,
but setting the limit just a bit over the reported
size, I'm afraid we'll likely run into that again rather
sooner than later.
IMO in an ideal world we'd never fail the sync due to file size
especially because the INotify code doesn't care about it either.
On 3/13/26 9:13 PM, Stoiko Ivanov wrote:
> the postfix configuration files are read via PVE::INotify in our
> stack and have not implicit limit.
>
> PMG::Cluster and PMG::Report do read the same file's contents using
> `file_get_contents` with a limit (explicitly set, or implicit) of 1M.
>
> This causes the cluster-sync to fail in one reported deployment
> hosting ~40k domains, with explicit transport entries and comments
> (resulting in a 1.4M /etc/pmg/transport).
>
> As it's the first occurrence of this causing an issue doubling the
> limit to 2M, instead of increasing it further seems appropriate.
>
> Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
> ---
> src/PMG/Cluster.pm | 4 ++--
> src/PMG/Report.pm | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/src/PMG/Cluster.pm b/src/PMG/Cluster.pm
> index 02d727ee..380cfa6e 100644
> --- a/src/PMG/Cluster.pm
> +++ b/src/PMG/Cluster.pm
> @@ -266,10 +266,10 @@ my $cond_commit_synced_file = sub {
> return;
> }
>
> - my $new = PVE::Tools::file_get_contents($srcfn, 1024 * 1024);
> + my $new = PVE::Tools::file_get_contents($srcfn, 2048 * 1024);
>
> if (-f $dstfn) {
> - my $old = PVE::Tools::file_get_contents($dstfn, 1024 * 1024);
> + my $old = PVE::Tools::file_get_contents($dstfn, 2048 * 1024);
> return 0 if $new eq $old;
> }
>
> diff --git a/src/PMG/Report.pm b/src/PMG/Report.pm
> index 84d1b887..20e4055d 100644
> --- a/src/PMG/Report.pm
> +++ b/src/PMG/Report.pm
> @@ -72,7 +72,7 @@ sub dir2text {
> sub {
> my ($file) = @_;
> $report .= "\n# cat $target_dir$file\n";
> - $report .= PVE::Tools::file_get_contents($target_dir . $file) . "\n";
> + $report .= PVE::Tools::file_get_contents($target_dir . $file, 2048 * 1024) . "\n";
> },
> );
> }
next prev parent reply other threads:[~2026-03-16 10:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-13 20:13 Stoiko Ivanov
2026-03-16 10:53 ` Dominik Csapak [this message]
2026-03-16 12:00 ` Stoiko Ivanov
2026-03-16 12:19 ` superseded: " Stoiko Ivanov
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=f14b8860-0835-4cdd-9143-027785d5e864@proxmox.com \
--to=d.csapak@proxmox.com \
--cc=pmg-devel@lists.proxmox.com \
--cc=s.ivanov@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.