On 27/10/22 8:09 pm, Philipp Rudo wrote:
Hi Hari,
Hi Philipp,
Thanks for the review.
On Fri, 21 Oct 2022 12:17:28 +0530
Hari Bathini <hbathini(a)linux.ibm.com> wrote:
> With commit fa9201b2 ("fadump: isolate fadump initramfs image within
> the default one"), initramfs image gets to hold two squash images, one
> for production kernel boot purpose and the other for capture kernel
> boot. Having separate images improved reliability for both production
> kernel and capture kernel boot scenarios, but the size of initramfs
> image became considerably larger.
>
> Instead of having squash images, compressing $initdir without using
> squash images reduced the size of initramfs image for fadump case by
> around 30%. So, avoid using squash for fadump case.
>
> Signed-off-by: Hari Bathini <hbathini(a)linux.ibm.com>
> ---
> kdump-lib.sh | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/kdump-lib.sh b/kdump-lib.sh
> index 817652d..543b5d1 100755
> --- a/kdump-lib.sh
> +++ b/kdump-lib.sh
> @@ -23,6 +23,13 @@ is_fadump_capable()
>
> is_squash_available()
> {
> + # Don't use squash with fadump as it creates two squash images within the
> + # same initramfs image, which negatively impacts compression ratio &
> + # increases the size of the initramfs image.
> + if is_fadump_capable; then
> + return 1
> + fi
> +
I absolutely don't like this patch. You are basically turning all
is_squash_available calls to noops for fadump. Including the ones in
mkfadumprd from witch one reads
Agreed. Polluting is_squash_available() for fadump case doesn't sound
right. Will respin with this fixed.
Thanks
Hari