openEuler20.03-LTS-SP1 raid4 出现D状态

【标题描述】能够简要描述问题：说明什么场景下，做了什么操作，出现什么问题（尽量使用正向表达方式）
【环境信息】
openEuler20.03-LTS-SP1
【问题复现步骤】
具体操作步骤
使用/dev/sdb 和 /dev/sdc 创建raid4设备，执行以下脚本

rescan.sh

#!/bin/bash

while true
do
        echo 1 > /sys/block/sdb/device/delete
        echo 1 > /sys/block/sdc/device/delete
        sleep 5
        echo '- - -' > /sys/class/scsi_host/host0/scan
        sleep 5
done

read.sh

#!/bin/bash

while true
do
        dd if=/dev/md2 of=/dev/null bs=4K count=100 iflag=direct
        sleep 0.1
done

【预期结果】
正常执行，不会出现D状态
【实际结果】
md2_raid4 线程占用100%，对raid4操作进行D状态。
【附件信息】
输入图片说明

Hi ***wguanghao***, welcome to the openEuler Community.
I'm the Bot here serving you. You can find the instructions on how to interact with me at **[Here](https://gitee.com/openeuler/community/blob/master/en/sig-infrastructure/command.md)**.
If you have any questions, please contact the SIG: [Kernel](https://gitee.com/openeuler/community/tree/master/sig/Kernel), and any of the maintainers: @xiexiuqi , @yangyingliang , @gatieme , @jiaoff , @guohaocs2c , @hanjun-guo , @woqidaideshi , @zhengzengkai , @newbeats , @zhangyi089 , @colyli , @thundertown , @htforge , @chiqijun , @lengchao , @zhujianwei001 , @kylin-mayukun , @wangxiongfeng , @wkfxxx , @SuperSix173 , @jentlestea , @oskernel0719 , @gasonchen , @kailiu42 , @whoisxxx , @wuxu_buque , @koulihong , @liuxinux , @kevinzhu1 , @xukuohai , @alvin-ling , @juntianlinux , @chenguangli , @zhenpengzheng , @LiuYongQiang0816 , @yuzenghui , @qiuuuuu , @haochengxie , @chenwei_kernel , @CTC-XiboWang , @x56Jason , @yuehaibing_planb , @guzitao , @Hongchen_Zhang

和wuguanghao对了，暂时没有在22.03-LTS-SP1上验证，
让guanghao在RC3上测试后确认有问题再关联22.03-LTS-SP1里程牌

md2_raid4 线程占用100%

测试脚本本地无法复现出守护进程占用100%
100%说明守护进程正在做事情，有确认过当前守护进程正在干什么吗？比如直接删盘导致大量的io出错，守护进程正在处理错误的io

22.03-LTS-SP1经验证，能够复现。

22.03-LTS-SP1 调用栈
[root@localhost ~]# ps -aux |grep D
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root        1623  0.0  0.0  17272  6160 ?        Ss   Oct31   0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
root        1630  0.0  0.0  71600  3812 ?        Ssl  Oct31   0:00 /usr/sbin/gssproxy -D
root      124113  0.0  0.0   3348  1584 ?        Ds   Oct31   0:00 /sbin/mdadm --monitor --scan --syslog -f --pid-file=/run/mdadm/mdadm.pid
root      126458  0.0  0.0   3116  1712 ?        D    Oct31   0:00 /usr/sbin/mdadm --detail --no-devices --export /dev/md2
root      126589  0.0  0.0   2668  1384 pts/0    D<   Oct31   0:00 /opt/fsstress/fsstress -d /mnt/ -p 8 -n 500 -l 50
root      126590  0.0  0.0   2668   128 pts/0    D<   Oct31   0:00 /opt/fsstress/fsstress -d /mnt/ -p 8 -n 500 -l 50
root      126591  0.0  0.0   2804  1432 pts/0    D<   Oct31   0:00 /opt/fsstress/fsstress -d /mnt/ -p 8 -n 500 -l 50
root      126592  0.0  0.0   2668   128 pts/0    D<   Oct31   0:00 /opt/fsstress/fsstress -d /mnt/ -p 8 -n 500 -l 50
root      126593  0.0  0.0   2672  1468 pts/0    D<   Oct31   0:00 /opt/fsstress/fsstress -d /mnt/ -p 8 -n 500 -l 50
root      126594  0.0  0.0   2804  1464 pts/0    D<   Oct31   0:00 /opt/fsstress/fsstress -d /mnt/ -p 8 -n 500 -l 50
root      126595  0.0  0.0   2668   128 pts/0    D<   Oct31   0:00 /opt/fsstress/fsstress -d /mnt/ -p 8 -n 500 -l 50
root      126596  0.0  0.0   2668   128 pts/0    D<   Oct31   0:00 /opt/fsstress/fsstress -d /mnt/ -p 8 -n 500 -l 50
root      127097  0.0  0.0  20804   768 pts/0    D<+  Oct31   0:00 sync
root      128600  0.0  0.0   3116  1696 ?        D    Oct31   0:00 /usr/sbin/mdadm --detail --no-devices --export /dev/md2
root      130395  0.0  0.0   3116  1716 ?        D    Oct31   0:00 /usr/sbin/mdadm --detail --no-devices --export /dev/md2
root      132190  0.0  0.0   3116  1604 ?        D    Oct31   0:00 /usr/sbin/mdadm --detail --no-devices --export /dev/md2
root      711174  0.0  0.0   3116  1708 pts/1    D+   09:40   0:00 mdadm -D /dev/md2
root      733619  0.0  0.0  21724  1920 pts/2    S+   10:17   0:00 grep --color=auto D
[root@localhost ~]# cat /proc/126458/stack
[<0>] __switch_to+0x7c/0xbc
[<0>] wait_on_page_bit+0x1fc/0x3f4
[<0>] wait_on_page_read+0x54/0x1dc
[<0>] do_read_cache_page+0x19c/0x590
[<0>] read_cache_page+0x1c/0x30
[<0>] read_part_sector+0x50/0x190
[<0>] read_lba+0xcc/0x1f0
[<0>] find_valid_gpt.constprop.0+0xcc/0x36c
[<0>] efi_partition+0x6c/0x360
[<0>] check_partition+0x114/0x220
[<0>] blk_add_partitions+0x44/0x1c0
[<0>] bdev_disk_changed+0xb8/0x154
[<0>] __blkdev_get+0x474/0x7b4
[<0>] blkdev_get+0x58/0xec
[<0>] blkdev_open+0x9c/0xb4
[<0>] do_dentry_open+0x134/0x404
[<0>] vfs_open+0x34/0x40
[<0>] do_open+0x1dc/0x30c
[<0>] path_openat+0x114/0x1e0
[<0>] do_filp_open+0x88/0x140
[<0>] do_sys_openat2+0x210/0x2f0
[<0>] __arm64_sys_openat+0x70/0xc0
[<0>] el0_svc_common.constprop.0+0x7c/0x1bc
[<0>] do_el0_svc+0x2c/0xa4
[<0>] el0_svc+0x20/0x30
[<0>] el0_sync_handler+0xb0/0xb4
[<0>] el0_sync+0x160/0x180
[root@localhost ~]# cat /proc/128600/stack
[<0>] __switch_to+0x7c/0xbc
[<0>] __blkdev_get+0xd8/0x7b4
[<0>] blkdev_get+0x58/0xec
[<0>] blkdev_open+0x9c/0xb4
[<0>] do_dentry_open+0x134/0x404
[<0>] vfs_open+0x34/0x40
[<0>] do_open+0x1dc/0x30c
[<0>] path_openat+0x114/0x1e0
[<0>] do_filp_open+0x88/0x140
[<0>] do_sys_openat2+0x210/0x2f0
[<0>] __arm64_sys_openat+0x70/0xc0
[<0>] el0_svc_common.constprop.0+0x7c/0x1bc
[<0>] do_el0_svc+0x2c/0xa4
[<0>] el0_svc+0x20/0x30
[<0>] el0_sync_handler+0xb0/0xb4
[<0>] el0_sync+0x160/0x180
[root@localhost ~]#

测试脚本中同时删除了sdb和sdc，raid中的两块盘都被删除。
这样测试是因为有用户会在使用过程中将两块硬盘都拔除吗？

此问题长时间无响应，先关闭

src-openEuler/kernel

内容风险标识

评论 (7)

src-openEuler/kernel .gitee-modal { width: 500px !important; }

内容风险标识