generic/643: Fix for 1k block sizes for ext2 and ext3
authorCarlos Maiolino <>
Wed, 10 Nov 2021 12:41:19 +0000 (13:41 +0100)
committerEryu Guan <>
Sun, 14 Nov 2021 12:19:06 +0000 (20:19 +0800)
Currently this test fails on ext2 and ext3 filesystems using 1k block sizes,
because we set the maximum swap size the kernel is allowed to map according to
the mapping kernel created when enabling the original swap file.

But the translation from indirect block mapping to iomap extents associated with
the page alignment requirements imposed by iomap_swapfile_add_extent(), causes
this test to fail. The kernel end up mapping way less pages than the file
actually has.
After the file is extended by the test, the page alignment is not a problem
anymore and the kernel can use the whole space available in the swapfile,
written in its header, and this creates a variance bigger than what the current
test allows, making the tolerance check within the test to fail.

Fix this by using the swap size recorded in the swapfile header (reported by
mkswap), as the maximum swap size the kernel is allowed to map, instead of
reading the swap size mapped by the kernel from /proc. This also makes
the first swap{on/off} cycle unnecessary, so remove it.

Since the size hardcoded in the swapfile header is the limit allowed for the
kernel to map as swap area, this is the real limit the kernel can't map beyond,
and what this test should be checking for.

This patch also slightly changes the way the test check the swap size
'after' the swap file is extended. Instead of retrieving the information
from /proc/swaps directly, the test now relies on 'swapon' tool. This
enables the test to retrieve the swap size in bytes directly, same unit
returned by _format_swapfile. This avoid possible miscalculations caused by
retrieving swap size in different units.

Signed-off-by: Carlos Maiolino <>
Reviewed-by: Eryu Guan <>
Signed-off-by: Eryu Guan <>

index 7a1d3ec7c54323e0dbe56695f627793c3b980c34..9a0ec2c3809c51f61532d86370a2b6092007b3a2 100755 (executable)
@@ -36,34 +36,25 @@ _scratch_mount >> $seqres.full
 # Assuming we're not borrowing a FAT16 partition from Windows 3.1, we need an
 # unlikely enough name that we can grep /proc/swaps for this.
-_format_swapfile $swapfile 1m >> $seqres.full
+before_blocks=$(_format_swapfile $swapfile 1m)
 page_size=$(getconf PAGE_SIZE)
-swapfile_blocks() {
-       local swapfile="$1"
-       grep "$swapfile" /proc/swaps | awk '{print $3}'
-_swapon_file $swapfile
-before_blocks=$(swapfile_blocks "$swapfile")
-swapoff $swapfile
 # Extend the length of the swapfile but do not rewrite the header.
 # The subsequent swapon should set up 1MB worth of blocks, not 2MB.
 $XFS_IO_PROG -f -c 'pwrite 1m 1m' $swapfile >> $seqres.full
 _swapon_file $swapfile
-after_blocks=$(swapfile_blocks "$swapfile")
+after_blocks=$(swapon --show --bytes |grep $swapfile | awk '{print $3}')
 swapoff $swapfile
-# Both swapon attempts should have found approximately the same number of
-# blocks.  Unfortunately, mkswap and the kernel are a little odd -- the number
-# of pages that mkswap writes into the swapfile header is one page less than
-# the file size, and then the kernel itself doesn't always grab all the pages
-# advertised in the header.  Hence we let the number of swap pages increase by
-# two pages.  I'm looking at you, Mr. 64k pages on arm64...
+# The swapon attempt should have found approximately the same number of blocks
+# originally created by the mkswap.
+# Unfortunately, mkswap and the kernel are a little odd -- the number of pages
+# that mkswap writes into the swapfile header is one page less than the file
+# size, and then the kernel itself doesn't always grab all the pages advertised
+# in the header. Such cases include ext2 and ext3 with 1k block size and arm64
+# with its 64k pages. Hence we let the number of swap pages increase by two pages.
 page_variance=$(( page_size / 512 ))
 _within_tolerance "swap blocks" $after_blocks $before_blocks 0 $page_variance -v