In preparation for fixing #6285 [0].
`0` means to just skip writing the module parameter. But (especially)
with the upcoming change in ZFS 2.3 - which makes the size basically
that of the system memory minus 1 GiB - we want to always write some
value.
[0] https://bugzilla.proxmox.com/show_bug.cgi?id=6285
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Reduce the maximum ARC size to 10% of total memory instead of the
default 50% not only for PVE, but always if the system has less than 2
GiB, or less than 4 GiB for PMG, i.e. less than the recommended
minimum memory we document.
We might want to fine-tune this further in the future, e.g. so that
PMG and PDM won't use 50% of memory even if they got more memory
installed. As they both are not IO-heavy, thus a big ARC won't gain
one that much, but as memory is mainly used for the base system there,
unlike PVE where it's mainly for virtual guests, it might make sense
to use something like 25% there for a better trade-of. Anyway, that's
something that needs closer evaluation, so not relevant for now.
Adapt the tests accordingly.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
To not allow the max ARC size to be the same as the total memory size.
Note that 1 GiB is often still not enough for a fully working system,
but for one, this can only happen if the user manually overrides ARC
max, and for another, it's only a general crude safety net to allow
the basic system to boot so that one can correct this if it's a
problem as for some products, like PBS or PDM, the base system's RSS
usage might be below 1 GiB, and we are not doing product-aware stuff
here.
Adapt the tests accordingly.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Co-authored-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
.. such that receivers can differentiate between these two cases more
clearly.
Sometimes, the `progress` sub does not get passed a text (on purpose!),
just updating the progress ratio. This would cause log messages to be
written out which could indicate missing text and look rather weird.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Previously, if something failed in the child, the overall test would
still be successful and exit with `0`.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Will be used for prompting the user to rename existing "rpool" ZFS
pools, similar to what we do for an existing LVM "pve" volume group.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Reviewed-by: Aaron Lauterer <a.lauterer@proxmox.com>
Tested-by: Aaron Lauterer <a.lauterer@proxmox.com>
[ TL: added a bit context for what this will be used and merge in the
tests into this preparatory commit ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
use modern calling style, avoid duplicate use of Test::More module,
handle fork error more visible, handle pipe creation errors and do
that all in one commit as it's just a test and I don't care.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Due to interpolation, the \. sequence must be double-escaped.
Previously, this would result in a non-escaped dot, thus matching much
more liberally than it should.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
[ TL: fix bug # reference in code comments ]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
.. by moving it into its own subroutine. Makes the whole thing quite a
bit neater and easier to maintain.
No functional changes.
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
Previously, the I/O loop would continue endlessly until the subprocess
exited.
This explicit handling allows run_command() to be used with e.g.
alarm().
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
This moves the kill() + waitpid() combo into a separate subroutine,
avoiding open-coding that sequence. wait_for_process() also handles
properly unkillable process (e.g. in D-state) and avoids completely
locking up the installer in such cases. See [0].
For the latter case, a timeout exists (with a default of 5 seconds) in
which to wait for the process to exit after sending an optional
TERM/KILL signal.
Also while at it, add a few basic tests for run_command().
[0] https://lists.proxmox.com/pipermail/pve-devel/2024-February/061697.html
Signed-off-by: Christoph Heiss <c.heiss@proxmox.com>
