Skip to content

Md tests - #256

Open
schlad wants to merge 8 commits into
linux-blktests:masterfrom
schlad:md_tests
Open

Md tests#256
schlad wants to merge 8 commits into
linux-blktests:masterfrom
schlad:md_tests

Conversation

@schlad

@schlad schlad commented Jul 29, 2026

Copy link
Copy Markdown
Contributor

No description provided.

schlad added 8 commits July 28, 2026 09:15
@schlad
tests/md/rc: add mdadm --detail parsing helpers
fbfaccb 
Adds _md_detail(), _md_is_level(), _md_is_healthy(), and
_md_is_faulty() to check an array's raid level and health via
mdadm --detail --export and --test

Signed-off-by: Sebastian Chlad <sebastian.chlad@suse.com>
@schlad
md: add basic RAID 0 creation sanity test
a89ae3c 
Creates a 2-device RAID 0 array on brd-backed ram disks, verifies it
comes up active, writes to it with fio, then tears it down.

Signed-off-by: Sebastian Chlad <sebastian.chlad@suse.com>
@schlad
md: add basic RAID 1 creation sanity test
de3c146 
Creates a 2-device RAID 1 array on brd-backed ram disks, verifies it
comes up active, writes to it with fio, then tears it down.

Signed-off-by: Sebastian Chlad <sebastian.chlad@suse.com>
@schlad
md: add basic RAID 5 creation sanity test
0fb535e 
Creates a 3-device RAID 5 array on brd-backed ram disks, verifies it
comes up active, writes to it with fio, then tears it down.

Signed-off-by: Sebastian Chlad <sebastian.chlad@suse.com>
@schlad
md: add basic RAID 6 creation sanity test
1b24f86 
Creates a 4-device RAID 6 array on brd-backed ram disks, verifies it
comes up active, writes to it with fio, then tears it down.

Signed-off-by: Sebastian Chlad <sebastian.chlad@suse.com>
@schlad
md: add basic RAID 10 creation sanity test
6e59f23 
Creates a 4-device RAID 10 array on brd-backed ram disks, verifies it
comes up active, writes to it with fio, then tears it down.

Signed-off-by: Sebastian Chlad <sebastian.chlad@suse.com>
@schlad
md: add RAID 5 creation sanity test on real block devices
61ef8f1 
Creates a 3-device RAID 5 array on real devices from TEST_DEV_ARRAY,
verifies it comes up active, writes to it with fio, then tears it
down. Unlike md/007 (brd-backed), this exercises real device I/O,
which is what can surface timing-dependent issues brd's near-instant
ram-backed I/O cannot reproduce.

Signed-off-by: Sebastian Chlad <sebastian.chlad@suse.com>
@schlad
md: add raid1 write-vs-recovery race reproducer on real devices
d5a9551 
Reproduces a NULL pointer dereference in wait_for_serialization()/
raid1_write_request() when a write races a fail - remove - add -
recovery transition while a filesystem writer is still active.

Fixes an ordering bug from an earlier version of this test: the wait
loop checked for the device to reach 'removed' state before --remove
was ever called, so it would spin its full timeout and fail on
output-diff every run regardless of whether the race triggered. Also
adds a bounded wait confirming recovery actually starts before racing
the writer against it, and a timeout on the initial mdadm --wait so a
stalled resync fails the test instead of hanging it.

Signed-off-by: Sebastian Chlad <sebastian.chlad@suse.com>
igaw
igaw reviewed Jul 29, 2026
View reviewed changes
Comment thread tests/md/006

local mddev="/dev/md/blktests_md_${TEST_NAME##*/}"

if ! _init_brd rd_size=524288 rd_nr=2; then

@igaw igaw Jul 29, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

from past experience, usually it's better to calculate the values not hard code them in case they are depended on the drive.

@schlad schlad Jul 29, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good point.
I looked how md/001 is doing that and I did that in the similar way, but yeah I agree.

@igaw igaw Jul 29, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, sorry, sometimes you just start pulling a thread....

@schlad schlad mentioned this pull request Jul 29, 2026
Open
@kawasaki

kawasaki commented Jul 31, 2026

Copy link
Copy Markdown
Collaborator

Thanks, I took a look in the commits and they look good overall. Let me leave a few comments.

  • As discussed, duplication in test cases from md/005 to md/009 should be avoided. I suggest to combine them into a single test case, but this is not a strong opinion. There could be other way to avoid the duplication.

  • There are some short options such as "mkdir -p" or "grep -q", and I would suggest to use long options for them, but this is a nit comment.

  • When I ran md/011 on v7.2-rc5 kernel, it passed at the 1st run. It failed at 2nd run with the message below:

md/011 => nvme0n1 nvme2n1 nvme3n1 nvme4n1 (reproduce raid1 write-vs-recovery race with concurrent I/O on ext4) [failed]
    runtime  11.084s  ...  15.817sests/blktests/results/tmpdir.md.011.3BS/mnt': Device or resource busy
    --- tests/md/011.out        2026-07-31 18:14:00.508000000 +0900
    +++ /home/shin/Blktests/blktests/results/nvme0n1_nvme2n1_nvme3n1_nvme4n1/md/011.out.bad     2026-07-31 18:29:22.746000000 +0900
    @@ -1,2 +1,6 @@
     Running md/011
    +mdadm: cannot open /dev/nvme0n1: Device or resource busy
    +timed out waiting for initial resync to finish
    +/dev/md/blktests_md_011 is mounted; will not make a filesystem here!
    +timed out waiting for recovery to start
     Test complete

Is this the expected failure?

I also wonder if md/011 has corresponding kernel side fix commit or not.

@schlad

schlad commented Jul 31, 2026

Copy link
Copy Markdown
Contributor Author

Thanks, I took a look in the commits and they look good overall. Let me leave a few comments.

* As discussed, duplication in test cases from md/005 to md/009 should be avoided. I suggest to combine them into a single test case, but this is not a strong opinion. There could be other way to avoid the duplication.

* There are some short options such as "mkdir -p" or "grep -q", and I would suggest to use long options for them, but this is a nit comment.

* When I ran md/011 on v7.2-rc5 kernel, it passed at the 1st run. It failed at 2nd run with the message below:

md/011 => nvme0n1 nvme2n1 nvme3n1 nvme4n1 (reproduce raid1 write-vs-recovery race with concurrent I/O on ext4) [failed]
    runtime  11.084s  ...  15.817sests/blktests/results/tmpdir.md.011.3BS/mnt': Device or resource busy
    --- tests/md/011.out        2026-07-31 18:14:00.508000000 +0900
    +++ /home/shin/Blktests/blktests/results/nvme0n1_nvme2n1_nvme3n1_nvme4n1/md/011.out.bad     2026-07-31 18:29:22.746000000 +0900
    @@ -1,2 +1,6 @@
     Running md/011
    +mdadm: cannot open /dev/nvme0n1: Device or resource busy
    +timed out waiting for initial resync to finish
    +/dev/md/blktests_md_011 is mounted; will not make a filesystem here!
    +timed out waiting for recovery to start
     Test complete

Is this the expected failure?

I also wonder if md/011 has corresponding kernel side fix commit or not.

Yes, the problem is known and there is a known fix. I will update the test information with the details.

Hmm I did not run it on v7.2-rc5 kernel; I will do and see why this is timing out in the 2nd run.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

1 more reviewer
@igaw igaw igaw left review comments
Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@schlad @kawasaki @igaw