leapp-repository/SOURCES/0015-lib-overlay-cap-the-max-size-of-disk-images.patch
eabdullin b61b49f950 Import from CS git
(cherry picked from commit ef02e9e53b)
2024-11-25 16:14:12 +02:00

67 lines
2.9 KiB
Diff

From cef2825778eb63f95e13cf48b1683bc98c32c21b Mon Sep 17 00:00:00 2001
From: Michal Hecko <mhecko@redhat.com>
Date: Fri, 25 Oct 2024 16:33:38 +0200
Subject: [PATCH 15/40] lib(overlay): cap the max size of disk images
On systems with large disks (e.g. 16TB) with lots of free space, leapp
might attemt to create files larger than the max file size of the
underlying FS. Attempting to create such large files causes leapp
to crash. This patch caps the max image size to 1TB, based on empirical
evidence that more free space is not needed for the upgrade RPM
transaction.
Jira-ref: RHEL-57064
---
.../common/libraries/overlaygen.py | 28 +++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/repos/system_upgrade/common/libraries/overlaygen.py b/repos/system_upgrade/common/libraries/overlaygen.py
index c1ac9ad3..867e3559 100644
--- a/repos/system_upgrade/common/libraries/overlaygen.py
+++ b/repos/system_upgrade/common/libraries/overlaygen.py
@@ -68,6 +68,27 @@ or close to that size, stay always with this minimal protected size defined by
this constant.
"""
+_MAX_DISK_IMAGE_SIZE_MB = 2**20 # 1*TB
+"""
+Maximum size of the created (sparse) images.
+
+Defaults to 1TB. If a disk with capacity larger than _MAX_DISK_IMAGE_SIZE_MB
+is mounted on the system, the corresponding image used to store overlay
+modifications will be capped to _MAX_DISK_IMAGE_SIZE_MB.
+
+Engineering rationale:
+ This constant was introduced to prevent leapp from creating files that are
+ virtually larger than the maximum file size supported by the file system.
+ E.g. if the source system hosts /var/lib/leapp on EXT4, then we cannot
+ create a file larger than 16TB.
+ We create these "disk images" to be able to verify the system has enough
+ disk space to perform the RPM upgrade transaction. From our experience,
+ we are not aware of any system which could have installed so much content
+ by RPMs that we would need 1TB of the free space on a single FS. Therefore,
+ we consider this value as safe while preventing us from exceeding FS
+ limits.
+"""
+
MountPoints = namedtuple('MountPoints', ['fs_file', 'fs_vfstype'])
@@ -287,6 +308,13 @@ def _prepare_required_mounts(scratch_dir, mounts_dir, storage_info, scratch_rese
disk_size = _get_fspace(mountpoint, convert_to_mibs=True, coefficient=0.95)
if mountpoint == scratch_mp:
disk_size = scratch_disk_size
+
+ if disk_size > _MAX_DISK_IMAGE_SIZE_MB:
+ msg = ('Image for overlayfs corresponding to the disk mounted at %s would ideally have %d MB, '
+ 'but we truncate it to %d MB to avoid bumping to max file limits.')
+ api.current_logger().info(msg, mountpoint, disk_size, _MAX_DISK_IMAGE_SIZE_MB)
+ disk_size = _MAX_DISK_IMAGE_SIZE_MB
+
image = _create_mount_disk_image(disk_images_directory, mountpoint, disk_size)
result[mountpoint] = mounting.LoopMount(
source=image,
--
2.47.0