[ndctl PATCH] test/rescan-partitions.sh: refine search for created partition

[ndctl PATCH] test/rescan-partitions.sh: refine search for created partition

[alison.schofield]

From: Alison Schofield <alison.schofield@intel.com>

Unit test rescan-partitions.sh can fail because the grep test looking
for the expected partition is overly broad and can match multiple
pmem devices.

/root/ndctl/build/meson-logs/testlog.txt reports this failure:
test/rescan-partitions.sh: failed at line 50

An example of an improper grep is:
'pmem10 pmem12 pmem1p1' when only 'pmem1p1' was expected

Replace the faulty grep with a query of the lsblk JSON output that
examines the children of this blockdev only and matches on size.

This type of pesky issue is probably arising as the unit tests are
being run in more complex environments and may also be due to other
unit tests not properly cleaning up after themselves. No matter the
cause this change makes this test more robust and that's a good thing!

Reported-by: Ira Weiny <ira.weiny@intel.com>
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
---
 test/rescan-partitions.sh | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/test/rescan-partitions.sh b/test/rescan-partitions.sh
index 51bbd731fb55..ccb542cb2f68 100755
--- a/test/rescan-partitions.sh
+++ b/test/rescan-partitions.sh
@@ -24,6 +24,7 @@ check_min_kver "4.16" || do_skip "may not contain fixes for partition rescanning
 
 check_prereq "parted"
 check_prereq "blockdev"
+check_prereq "jq"
 
 test_mode()
 {
@@ -46,7 +47,10 @@ test_mode()
 	sleep 1
 	blockdev --rereadpt /dev/$blockdev
 	sleep 1
-	partdev="$(grep -Eo "${blockdev}.+" /proc/partitions)"
+	partdev=$(lsblk -J -o NAME,SIZE /dev/$blockdev |
+		jq -r '.blockdevices[] | .children[] |
+		select(.size == "9M") | .name')
+
 	test -b /dev/$partdev
 
 	# cycle the namespace, and verify the partition is read
-- 
2.37.3

Re: [ndctl PATCH] test/rescan-partitions.sh: refine search for created partition

[Verma, Vishal L]

On Wed, 2024-08-28 at 12:26 -0700, alison.schofield@intel.com wrote:
> From: Alison Schofield <alison.schofield@intel.com>
> 
> Unit test rescan-partitions.sh can fail because the grep test looking
> for the expected partition is overly broad and can match multiple
> pmem devices.
> 
> /root/ndctl/build/meson-logs/testlog.txt reports this failure:
> test/rescan-partitions.sh: failed at line 50
> 
> An example of an improper grep is:
> 'pmem10 pmem12 pmem1p1' when only 'pmem1p1' was expected
> 
> Replace the faulty grep with a query of the lsblk JSON output that
> examines the children of this blockdev only and matches on size.
> 
> This type of pesky issue is probably arising as the unit tests are
> being run in more complex environments and may also be due to other
> unit tests not properly cleaning up after themselves. No matter the
> cause this change makes this test more robust and that's a good
> thing!
> 
> Reported-by: Ira Weiny <ira.weiny@intel.com>
> Signed-off-by: Alison Schofield <alison.schofield@intel.com>
> ---
>  test/rescan-partitions.sh | 6 +++++-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/test/rescan-partitions.sh b/test/rescan-partitions.sh
> index 51bbd731fb55..ccb542cb2f68 100755
> --- a/test/rescan-partitions.sh
> +++ b/test/rescan-partitions.sh
> @@ -24,6 +24,7 @@ check_min_kver "4.16" || do_skip "may not contain
> fixes for partition rescanning
>  
>  check_prereq "parted"
>  check_prereq "blockdev"
> +check_prereq "jq"
>  
>  test_mode()
>  {
> @@ -46,7 +47,10 @@ test_mode()
>  	sleep 1
>  	blockdev --rereadpt /dev/$blockdev
>  	sleep 1
> -	partdev="$(grep -Eo "${blockdev}.+" /proc/partitions)"
> +	partdev=$(lsblk -J -o NAME,SIZE /dev/$blockdev |
> +		jq -r '.blockdevices[] | .children[] |
> +		select(.size == "9M") | .name')

Hm slight reaction to the size == 9M check that wasn't there before.

Would it be better to just use .children[0].name instead of looking for
a specific 9M sized partition? May be more robust if the size ever
changes for some reason.

Otherwise looks good,

Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>