test: add zram compression tests for crypto_zstd and crypto_lz4#4390
test: add zram compression tests for crypto_zstd and crypto_lz4#4390rlmenge wants to merge 3 commits intomicrosoft:mainfrom
Conversation
Add a new ZramCompression test suite that validates zram block device functionality with zstd and lz4 compression algorithms on Azure Linux 3.0+. Each test case loads the crypto module and zram, configures the compression algorithm, creates an ext4 filesystem on the zram device, and verifies data integrity via write/read. Cleanup tears down the device and unloads modules in a finally block.
There was a problem hiding this comment.
Pull request overview
Adds a new LISA core test suite to validate zram block-device functionality using crypto_zstd and crypto_lz4 compression on Azure Linux (CBLMariner) 3.0+.
Changes:
- Introduces
ZramCompressiontest suite with two test cases covering zstd and lz4 zram compression backends. - Implements a shared helper that loads modules, configures zram via sysfs, formats/mounts ext4, and validates write/read integrity with cleanup.
Check mount point exists before calling umount in the finally block. If the test fails before mounting, umount raises on the missing mount point and masks the original error.
| # Clean up: unmount, reset zram, unload modules | ||
| mount_tool = node.tools[Mount] | ||
| if mount_tool.check_mount_point_exist(self._ZRAM_MOUNT_POINT): | ||
| mount_tool.umount("zram0", self._ZRAM_MOUNT_POINT, erase=False) |
There was a problem hiding this comment.
Mount.umount takes disk_name as its first positional parameter. Here it’s passed as the string "zram0" while the device used elsewhere is "/dev/zram0", and the call site relies on erase=False so the mismatch is currently harmless. To avoid future breakage (e.g., if erase is ever changed or the signature is refactored), use keyword arguments and pass a consistent disk_name (e.g., the same value as _ZRAM_DEVICE, or an empty string when erase=False).
| mount_tool.umount("zram0", self._ZRAM_MOUNT_POINT, erase=False) | |
| mount_tool.umount( | |
| disk_name=self._ZRAM_DEVICE, | |
| mount_point=self._ZRAM_MOUNT_POINT, | |
| erase=False, | |
| ) |
|
|
||
| # Check that the crypto module exists in the kernel | ||
| if not modprobe.module_exists(module): | ||
| raise SkippedException(f"Kernel module '{module}' is not available.") |
There was a problem hiding this comment.
Whether there is a possibility that the module doesn't load yet?
There was a problem hiding this comment.
Yes, that's expected — module_exists() runs modprobe --dry-run to check if the module is available in the kernel tree, not whether it's currently loaded. We load it on the next line. This check just lets us skip gracefully if the kernel doesn't include the module.
Add a new ZramCompression test suite that validates zram block device functionality with zstd and lz4 compression algorithms on Azure Linux 3.0+.
Each test case loads the crypto module and zram, configures the compression algorithm, creates an ext4 filesystem on the zram device, and verifies data integrity via write/read. Cleanup tears down the device and unloads modules in a finally block.
Description
Adds a new ZramCompression test suite that validates zram block device functionality with zstd and lz4 compression algorithms. The tests are restricted to Azure Linux 3.0+.
Test Cases
What Each Test Does
Related Issue
Type of Change
Checklist
Test Validation
Key Test Cases:
verify_zram_crypto_zstd|verify_zram_crypto_lz4
Impacted LISA Features:
None (uses Modprobe, Lsmod, Mount, Mkfs tools — no LISA features)
Tested Azure Marketplace Images:
MicrosoftCBLMariner:azure-linux-3:azure-linux-3:latestMicrosoftCBLMariner:azure-linux-3:azure-linux-3-arm64:latestCanonical:ubuntu-24_04-lts:server:latestTest Results
Note the following had an updated kernel from microsoft/azurelinux#16268
MicrosoftCBLMariner:azure-linux-3:azure-linux-3-arm64:latestMicrosoftCBLMariner:azure-linux-3:azure-linux-3:latestCanonical:ubuntu-24_04-lts:server:latest