LVM2 test breakage

LVM2 test breakage

[Mikulas Patocka]

Hi

The commit e879a0d9cb086c8e52ce6c04e5bfa63825a6213c breaks the test 
shell/lvcreate-large-raid.sh in the lvm2 testsuite.

The breakage is caused by removing the line "read_bio->bi_opf = op | 
do_sync;"

Mikulas

Re: LVM2 test breakage

[Yu Kuai]

Hi,

在 2025/05/17 0:00, Mikulas Patocka 写道:
> Hi
> 
> The commit e879a0d9cb086c8e52ce6c04e5bfa63825a6213c breaks the test
> shell/lvcreate-large-raid.sh in the lvm2 testsuite.
> 
> The breakage is caused by removing the line "read_bio->bi_opf = op |
> do_sync;"
> 

Sorry that I don't undertand here, before the patch:

op = bio_op(bio);
do_sync = bio->bi_opf & REQ_SYNC;
read_bio->bi_opf = op | do_sync

after the patch:

read_bio = bio_alloc_clone(, bio, ...)
  read_bio->bi_opf = bio->bi_opf

So, after the patch, other than bio_op() and REQ_SYNC, other bio flags
are keeped, I don't see problem for now, I'll run the test later.

Thanks,
Kuai

> Mikulas
> 
> 
> .
> 

Re: LVM2 test breakage

[Yu Kuai]

Hi,

在 2025/05/19 9:11, Yu Kuai 写道:
> Hi,
> 
> 在 2025/05/17 0:00, Mikulas Patocka 写道:
>> Hi
>>
>> The commit e879a0d9cb086c8e52ce6c04e5bfa63825a6213c breaks the test
>> shell/lvcreate-large-raid.sh in the lvm2 testsuite.
>>
>> The breakage is caused by removing the line "read_bio->bi_opf = op |
>> do_sync;"
>>
> 
> Sorry that I don't undertand here, before the patch:
> 
> op = bio_op(bio);
> do_sync = bio->bi_opf & REQ_SYNC;
> read_bio->bi_opf = op | do_sync
> 
> after the patch:
> 
> read_bio = bio_alloc_clone(, bio, ...)
>   read_bio->bi_opf = bio->bi_opf
> 
> So, after the patch, other than bio_op() and REQ_SYNC, other bio flags
> are keeped, I don't see problem for now, I'll run the test later.
> 

Do I need some special setup to run this test? I got following
result in my VM, and I don't understand why it failed.

Thanks,
Kuai

[root@fedora ~]# cat 
lvm2/test/results/ndev-vanilla\:shell_lvcreate-large-raid.sh.txt
[ 0:00.290] Library version:   1.02.199-git (2024-05-16)
[ 0:00.290] Driver version:    4.50.0
[ 0:00.290] Kernel is Linux fedora 
6.15.0-rc6-next-20250516-00001-ge4a42bdb48e2 #1064 SMP PREEMPT_DYNAMIC 
Mon May 19 14:18:47 CST 2025 x86_64 x86_64 x86_64 GNU/Linux
[ 0:00.351] Selinux mode is Disabled.
[ 0:00.365]                total        used        free      shared 
buff/cache   available
[ 0:00.384] Mem:          257561         576      256529           0 
     455      255165
[ 0:00.384] Swap:              0           0           0
[ 0:00.384] Filesystem      Size  Used Avail Use% Mounted on
[ 0:00.402] /dev/root        20G   18G  3.0G  86% /
[ 0:00.402] devtmpfs        126G     0  126G   0% /dev
[ 0:00.402] tmpfs           126G     0  126G   0% /dev/shm
[ 0:00.402] tmpfs            51G  952K   51G   1% /run
[ 0:00.402] tmpfs           4.0M     0  4.0M   0% /sys/fs/cgroup
[ 0:00.402] tmpfs           126G     0  126G   0% /tmp
[ 0:00.402] modules          14T   13T  1.4T  91% /tmp/modules
[ 0:00.402] tmpfs            26G     0   26G   0% /run/user/0
[ 0:00.402] /dev/nvme0n1     98G   56K   93G   1% /mnt/test
[ 0:00.402] @TESTDIR=/mnt/test/LVMTEST8522.QQ9T6A2cUU
[ 0:00.404] @PREFIX=LVMTEST8522
[ 0:00.404] ## DATE: Mon May 19 06:26:54 UTC 2025
[ 0:00.419] ## HOST: 192.168.8.196
[ 0:00.429] ## LVMCONF: activation {
[ 0:00.598] ## LVMCONF:     checks = 1
[ 0:00.598] ## LVMCONF:     monitoring = 0
[ 0:00.598] ## LVMCONF:     polling_interval = 1
[ 0:00.598] ## LVMCONF:     raid_region_size = 512
[ 0:00.598] ## LVMCONF:     retry_deactivation = 1
[ 0:00.598] ## LVMCONF:     snapshot_autoextend_percent = 50
[ 0:00.598] ## LVMCONF:     snapshot_autoextend_threshold = 50
[ 0:00.598] ## LVMCONF:     udev_rules = 1
[ 0:00.598] ## LVMCONF:     udev_sync = 1
[ 0:00.598] ## LVMCONF:     verify_udev_operations = 1
[ 0:00.598] ## LVMCONF: }
[ 0:00.598] ## LVMCONF: allocation {
[ 0:00.598] ## LVMCONF:     vdo_slab_size_mb = 128
[ 0:00.598] ## LVMCONF:     wipe_signatures_when_zeroing_new_lvs = 0
[ 0:00.598] ## LVMCONF:     zero_metadata = 0
[ 0:00.598] ## LVMCONF: }
[ 0:00.598] ## LVMCONF: backup {
[ 0:00.598] ## LVMCONF:     archive = 0
[ 0:00.598] ## LVMCONF:     backup = 0
[ 0:00.598] ## LVMCONF: }
[ 0:00.598] ## LVMCONF: devices {
[ 0:00.598] ## LVMCONF:     cache_dir = 
"/mnt/test/LVMTEST8522.QQ9T6A2cUU/etc"
[ 0:00.598] ## LVMCONF:     default_data_alignment = 1
[ 0:00.598] ## LVMCONF:     dir = "/mnt/test/LVMTEST8522.QQ9T6A2cUU/dev"
[ 0:00.598] ## LVMCONF:     filter = "a|.*|"
[ 0:00.598] ## LVMCONF:     global_filter = [ 
"a|/mnt/test/LVMTEST8522.QQ9T6A2cUU/dev/mapper/LVMTEST8522.*pv[0-9_]*$|", 
"r|.*|" ]
[ 0:00.598] ## LVMCONF:     md_component_detection = 0
[ 0:00.598] ## LVMCONF:     scan = "/mnt/test/LVMTEST8522.QQ9T6A2cUU/dev"
[ 0:00.598] ## LVMCONF:     sysfs_scan = 1
[ 0:00.598] ## LVMCONF:     use_devicesfile = 0
[ 0:00.598] ## LVMCONF:     write_cache_state = 0
[ 0:00.598] ## LVMCONF: }
[ 0:00.598] ## LVMCONF: dmeventd {
[ 0:00.598] ## LVMCONF:     executable = "/root/lvm2/test/lib/dmeventd"
[ 0:00.598] ## LVMCONF: }
[ 0:00.598] ## LVMCONF: global {
[ 0:00.598] ## LVMCONF:     abort_on_internal_errors = 1
[ 0:00.598] ## LVMCONF:     cache_check_executable = "/usr/sbin/cache_check"
[ 0:00.598] ## LVMCONF:     cache_dump_executable = "/usr/sbin/cache_dump"
[ 0:00.598] ## LVMCONF:     cache_repair_executable = 
"/usr/sbin/cache_repair"
[ 0:00.598] ## LVMCONF:     cache_restore_executable = 
"/usr/sbin/cache_restore"
[ 0:00.598] ## LVMCONF:     detect_internal_vg_cache_corruption = 1
[ 0:00.598] ## LVMCONF:     etc = "/mnt/test/LVMTEST8522.QQ9T6A2cUU/etc"
[ 0:00.598] ## LVMCONF:     event_activation = 1
[ 0:00.598] ## LVMCONF:     fallback_to_local_locking = 0
[ 0:00.598] ## LVMCONF:     fsadm_executable = "/root/lvm2/test/lib/fsadm"
[ 0:00.598] ## LVMCONF:     library_dir = 
"/mnt/test/LVMTEST8522.QQ9T6A2cUU/lib"
[ 0:00.598] ## LVMCONF:     locking_dir = 
"/mnt/test/LVMTEST8522.QQ9T6A2cUU/var/lock/lvm"
[ 0:00.598] ## LVMCONF:     locking_type=1
[ 0:00.598] ## LVMCONF:     notify_dbus = 0
[ 0:00.598] ## LVMCONF:     si_unit_consistency = 1
[ 0:00.598] ## LVMCONF:     thin_check_executable = "/usr/sbin/thin_check"
[ 0:00.598] ## LVMCONF:     thin_dump_executable = "/usr/sbin/thin_dump"
[ 0:00.598] ## LVMCONF:     thin_repair_executable = "/usr/sbin/thin_repair"
[ 0:00.598] ## LVMCONF:     thin_restore_executable = 
"/usr/sbin/thin_restore"
[ 0:00.598] ## LVMCONF:     use_lvmlockd = 0
[ 0:00.598] ## LVMCONF:     use_lvmpolld = 0
[ 0:00.598] ## LVMCONF: }
[ 0:00.598] ## LVMCONF: log {
[ 0:00.598] ## LVMCONF:     activation = 1
[ 0:00.598] ## LVMCONF:     file = 
"/mnt/test/LVMTEST8522.QQ9T6A2cUU/debug.log"
[ 0:00.598] ## LVMCONF:     indent = 1
[ 0:00.598] ## LVMCONF:     level = 9
[ 0:00.598] ## LVMCONF:     overwrite = 1
[ 0:00.598] ## LVMCONF:     syslog = 0
[ 0:00.598] ## LVMCONF:     verbose = 0
[ 0:00.598] ## LVMCONF: }
[ 0:00.598] <======== Processing test: "lvcreate-large-raid.sh" ========>
[ 0:00.612]
[ 0:00.613] # FIXME  update test to make something useful on <16T
[ 0:00.613] aux can_use_16T || skip
[ 0:00.613] #lvcreate-large-raid.sh:21+ aux can_use_16T
[ 0:00.613]
[ 0:00.688] aux have_raid 1 3 0 || skip
[ 0:00.688] #lvcreate-large-raid.sh:23+ aux have_raid 1 3 0
[ 0:00.688] v1_9_0=0
[ 0:00.867] #lvcreate-large-raid.sh:24+ v1_9_0=0
[ 0:00.867] aux have_raid 1 9 0 && v1_9_0=1
[ 0:00.867] #lvcreate-large-raid.sh:25+ aux have_raid 1 9 0
[ 0:00.867] #lvcreate-large-raid.sh:25+ v1_9_0=1
[ 0:01.082]
[ 0:01.083] segtypes="raid5"
[ 0:01.083] #lvcreate-large-raid.sh:27+ segtypes=raid5
[ 0:01.083] aux have_raid4 && segtypes="raid4 raid5"
[ 0:01.083] #lvcreate-large-raid.sh:28+ aux have_raid4
[ 0:01.083] #lvcreate-large-raid.sh:28+ segtypes='raid4 raid5'
[ 0:01.500]
[ 0:01.500] # Prepare 5x ~1P sized devices
[ 0:01.500] aux prepare_pvs 5 1000000000
[ 0:01.500] #lvcreate-large-raid.sh:31+ aux prepare_pvs 5 1000000000
[ 0:01.500] ## preparing loop device....set +vx; STACKTRACE; set -vx
[ 0:01.709] ##lvcreate-large-raid.sh:31+ set +vx
[ 0:01.709] ## - /root/lvm2/test/shell/lvcreate-large-raid.sh:31
[ 0:01.710] ## 1 STACKTRACE() called from 
/root/lvm2/test/shell/lvcreate-large-raid.sh:31
[ 0:01.710] <======== Free space ========>
[ 0:02.310] ## DF_H:    Filesystem      Size  Used Avail Use% Mounted on
[ 0:02.335] ## DF_H:    /dev/root        20G   18G  3.0G  86% /
[ 0:02.335] ## DF_H:    devtmpfs        126G     0  126G   0% /dev
[ 0:02.335] ## DF_H:    tmpfs           126G     0  126G   0% /dev/shm
[ 0:02.335] ## DF_H:    tmpfs            51G  952K   51G   1% /run
[ 0:02.335] ## DF_H:    tmpfs           4.0M     0  4.0M   0% /sys/fs/cgroup
[ 0:02.335] ## DF_H:    tmpfs           126G     0  126G   0% /tmp
[ 0:02.335] ## DF_H:    modules          14T   13T  1.4T  91% /tmp/modules
[ 0:02.335] ## DF_H:    tmpfs            26G     0   26G   0% /run/user/0
[ 0:02.335] ## DF_H:    /dev/nvme0n1     98G   64K   93G   1% /mnt/test
[ 0:02.335] <======== Script file "lvcreate-large-raid.sh" ========>
[ 0:02.345] ## Line: 1   #!/usr/bin/env bash
[ 0:02.384] ## Line: 2
[ 0:02.384] ## Line: 3   # Copyright (C) 2012,2016 Red Hat, Inc. All 
rights reserved.
[ 0:02.384] ## Line: 4   #
[ 0:02.384] ## Line: 5   # This copyrighted material is made available 
to anyone wishing to use,
[ 0:02.384] ## Line: 6   # modify, copy, or redistribute it subject to 
the terms and conditions
[ 0:02.384] ## Line: 7   # of the GNU General Public License v.2.
[ 0:02.384] ## Line: 8   #
[ 0:02.384] ## Line: 9   # You should have received a copy of the GNU 
General Public License
[ 0:02.384] ## Line: 10          # along with this program; if not, 
write to the Free Software Foundation,
[ 0:02.384] ## Line: 11          # Inc., 51 Franklin Street, Fifth 
Floor, Boston, MA 02110-1301 USA
[ 0:02.384] ## Line: 12
[ 0:02.384] ## Line: 13          # 'Exercise some lvcreate diagnostics'
[ 0:02.384] ## Line: 14
[ 0:02.384] ## Line: 15
[ 0:02.384] ## Line: 16          SKIP_WITH_LVMPOLLD=1
[ 0:02.384] ## Line: 17
[ 0:02.384] ## Line: 18          . lib/inittest
[ 0:02.384] ## Line: 19
[ 0:02.384] ## Line: 20          # FIXME  update test to make something 
useful on <16T
[ 0:02.384] ## Line: 21          aux can_use_16T || skip
[ 0:02.384] ## Line: 22
[ 0:02.384] ## Line: 23          aux have_raid 1 3 0 || skip
[ 0:02.384] ## Line: 24          v1_9_0=0
[ 0:02.384] ## Line: 25          aux have_raid 1 9 0 && v1_9_0=1
[ 0:02.384] ## Line: 26
[ 0:02.384] ## Line: 27          segtypes="raid5"
[ 0:02.384] ## Line: 28          aux have_raid4 && segtypes="raid4 raid5"
[ 0:02.384] ## Line: 29
[ 0:02.384] ## Line: 30          # Prepare 5x ~1P sized devices
[ 0:02.384] ## Line: 31          aux prepare_pvs 5 1000000000
[ 0:02.384] ## Line: 32          get_devs
[ 0:02.384] ## Line: 33
[ 0:02.384] ## Line: 34          vgcreate $SHARED "$vg1" "${DEVICES[@]}"
[ 0:02.384] ## Line: 35
[ 0:02.384] ## Line: 36          aux lvmconf 'devices/issue_discards = 1'
[ 0:02.384] ## Line: 37
[ 0:02.384] ## Line: 38          # Delay PVs so that resynchronization 
doesn't fill too much space
[ 0:02.384] ## Line: 39          for device in "${DEVICES[@]}"
[ 0:02.384] ## Line: 40          do
[ 0:02.384] ## Line: 41                 aux zero_dev "$device" "$(( 
$(get first_extent_sector "$device") + 8192 )):"
[ 0:02.384] ## Line: 42          done
[ 0:02.384] ## Line: 43
[ 0:02.384] ## Line: 44          # bz837927 START
[ 0:02.384] ## Line: 45
[ 0:02.384] ## Line: 46          #
[ 0:02.384] ## Line: 47          # Create large RAID LVs
[ 0:02.384] ## Line: 48          #
[ 0:02.384] ## Line: 49
[ 0:02.384] ## Line: 50          # 200 TiB raid1
[ 0:02.384] ## Line: 51          lvcreate --type raid1 -m 1 -L 200T -n 
$lv1 $vg1 --nosync
[ 0:02.384] ## Line: 52          check lv_field $vg1/$lv1 size "200.00t"
[ 0:02.384] ## Line: 53          check raid_leg_status $vg1 $lv1 "AA"
[ 0:02.384] ## Line: 54          lvremove -ff $vg1
[ 0:02.384] ## Line: 55
[ 0:02.384] ## Line: 56          # 1 PiB raid1
[ 0:02.384] ## Line: 57          lvcreate --type raid1 -m 1 -L 1P -n 
$lv1 $vg1 --nosync
[ 0:02.384] ## Line: 58          check lv_field $vg1/$lv1 size "1.00p"
[ 0:02.384] ## Line: 59          check raid_leg_status $vg1 $lv1 "AA"
[ 0:02.384] ## Line: 60          lvremove -ff $vg1
[ 0:02.384] ## Line: 61
[ 0:02.384] ## Line: 62          # 750 TiB raid4/5
[ 0:02.384] ## Line: 63          for segtype in $segtypes; do
[ 0:02.384] ## Line: 64                  lvcreate --type $segtype -i 3 
-L 750T -n $lv1 $vg1 --nosync
[ 0:02.384] ## Line: 65                  check lv_field $vg1/$lv1 size 
"750.00t"
[ 0:02.384] ## Line: 66                  check raid_leg_status $vg1 $lv1 
"AAAA"
[ 0:02.384] ## Line: 67                  lvremove -ff $vg1
[ 0:02.384] ## Line: 68          done
[ 0:02.384] ## Line: 69
[ 0:02.384] ## Line: 70          #
[ 0:02.384] ## Line: 71          # Extending large 200 TiB RAID LV to 
400 TiB (belong in different script?)
[ 0:02.384] ## Line: 72          #
[ 0:02.384] ## Line: 73          lvcreate --type raid1 -m 1 -L 200T -n 
$lv1 $vg1 --nosync
[ 0:02.384] ## Line: 74          check lv_field $vg1/$lv1 size "200.00t"
[ 0:02.384] ## Line: 75          check raid_leg_status $vg1 $lv1 "AA"
[ 0:02.384] ## Line: 76          lvextend -L +200T $vg1/$lv1
[ 0:02.384] ## Line: 77          check lv_field $vg1/$lv1 size "400.00t"
[ 0:02.384] ## Line: 78          check raid_leg_status $vg1 $lv1 "AA"
[ 0:02.384] ## Line: 79          lvremove -ff $vg1
[ 0:02.384] ## Line: 80
[ 0:02.384] ## Line: 81
[ 0:02.384] ## Line: 82          # Check --nosync is rejected for raid6
[ 0:02.384] ## Line: 83          if [ $v1_9_0 -eq 1 ] ; then
[ 0:02.384] ## Line: 84                 not lvcreate --type raid6 -i 3 
-L 750T -n $lv1 $vg1 --nosync
[ 0:02.384] ## Line: 85          fi
[ 0:02.384] ## Line: 86
[ 0:02.384] ## Line: 87          # 750 TiB raid6
[ 0:02.384] ## Line: 88          lvcreate --type raid6 -i 3 -L 750T -n 
$lv1 $vg1
[ 0:02.384] ## Line: 89          check lv_field $vg1/$lv1 size "750.00t"
[ 0:02.384] ## Line: 90          check raid_leg_status $vg1 $lv1 "aaaaa"
[ 0:02.384] ## Line: 91          lvremove -ff $vg1
[ 0:02.384] ## Line: 92
[ 0:02.384] ## Line: 93          # 1 PiB raid6, then extend up to 2 PiB
[ 0:02.384] ## Line: 94          lvcreate --type raid6 -i 3 -L 1P -n 
$lv1 $vg1
[ 0:02.384] ## Line: 95          check lv_field $vg1/$lv1 size "1.00p"
[ 0:02.384] ## Line: 96          check raid_leg_status $vg1 $lv1 "aaaaa"
[ 0:02.384] ## Line: 97          lvextend -L +1P $vg1/$lv1
[ 0:02.384] ## Line: 98          check lv_field $vg1/$lv1 size "2.00p"
[ 0:02.384] ## Line: 99          check raid_leg_status $vg1 $lv1 "aaaaa"
[ 0:02.384] ## Line: 100         lvremove -ff $vg1
[ 0:02.384] ## Line: 101
[ 0:02.384] ## Line: 102         #
[ 0:02.384] ## Line: 103         # Convert large 200 TiB linear to RAID1 
(belong in different test script?)
[ 0:02.384] ## Line: 104         #
[ 0:02.384] ## Line: 105         lvcreate -aey -L 200T -n $lv1 $vg1
[ 0:02.384] ## Line: 106         lvconvert -y --type raid1 -m 1 $vg1/$lv1
[ 0:02.384] ## Line: 107         check lv_field $vg1/$lv1 size "200.00t"
[ 0:02.384] ## Line: 108         if [ $v1_9_0 -eq 1 ] ; then
[ 0:02.384] ## Line: 109                # The 1.9.0 version of dm-raid 
is capable of performing
[ 0:02.384] ## Line: 110                # linear -> RAID1 upconverts as 
"recover" not "resync"
[ 0:02.384] ## Line: 111                # The LVM code now checks the 
dm-raid version when
[ 0:02.384] ## Line: 112                # upconverting and if 1.9.0+ is 
found, it uses "recover"
[ 0:02.384] ## Line: 113                check raid_leg_status $vg1 $lv1 "Aa"
[ 0:02.384] ## Line: 114         else
[ 0:02.384] ## Line: 115                check raid_leg_status $vg1 $lv1 "aa"
[ 0:02.384] ## Line: 116         fi
[ 0:02.384] ## Line: 117         lvremove -ff $vg1
[ 0:02.384] ## Line: 118
[ 0:02.384] ## Line: 119         # bz837927 END
[ 0:02.384] ## Line: 120
[ 0:02.384] ## Line: 121         vgremove -ff $vg1
[ 0:02.384] aux teardown
[ 0:02.394] #lvcreate-large-raid.sh:1+ aux teardown
[ 0:02.394] ## teardown.........ok

> Thanks,
> Kuai
> 
>> Mikulas
>>
>>
>> .
>>
> 
> .
> 

Re: LVM2 test breakage

[Mikulas Patocka]

[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]



On Mon, 19 May 2025, Yu Kuai wrote:

> Hi,
> 
> 在 2025/05/19 9:11, Yu Kuai 写道:
> > Hi,
> > 
> > 在 2025/05/17 0:00, Mikulas Patocka 写道:
> > > Hi
> > > 
> > > The commit e879a0d9cb086c8e52ce6c04e5bfa63825a6213c breaks the test
> > > shell/lvcreate-large-raid.sh in the lvm2 testsuite.
> > > 
> > > The breakage is caused by removing the line "read_bio->bi_opf = op |
> > > do_sync;"
> > > 
> > 
> > Sorry that I don't undertand here, before the patch:
> > 
> > op = bio_op(bio);
> > do_sync = bio->bi_opf & REQ_SYNC;
> > read_bio->bi_opf = op | do_sync
> > 
> > after the patch:
> > 
> > read_bio = bio_alloc_clone(, bio, ...)
> >   read_bio->bi_opf = bio->bi_opf
> > 
> > So, after the patch, other than bio_op() and REQ_SYNC, other bio flags
> > are keeped, I don't see problem for now, I'll run the test later.
> > 
> 
> Do I need some special setup to run this test? I got following
> result in my VM, and I don't understand why it failed.
> 
> Thanks,
> Kuai

Ask Zdenek Kabelac - he is expert in the testsuite.

Mikulas

Re: LVM2 test breakage

[Yu Kuai]

Hi,

在 2025/05/19 18:45, Zdenek Kabelac 写道:
> Dne 19. 05. 25 v 12:10 Mikulas Patocka napsal(a):
>> On Mon, 19 May 2025, Yu Kuai wrote:
>>
>>> Hi,
>>>
>>> 在 2025/05/19 9:11, Yu Kuai 写道:
>>>> Hi,
>>>>
>>>> 在 2025/05/17 0:00, Mikulas Patocka 写道:
>>>>> Hi
>>>>>
>>>>> The commit e879a0d9cb086c8e52ce6c04e5bfa63825a6213c breaks the test
>>>>> shell/lvcreate-large-raid.sh in the lvm2 testsuite.
>>>>>
>>>>> The breakage is caused by removing the line "read_bio->bi_opf = op |
>>>>> do_sync;"
>>>>>
>>> Do I need some special setup to run this test? I got following
>>> result in my VM, and I don't understand why it failed.
>>>
>>> Ask Zdenek Kabelac - he is expert in the testsuite.
>>>
>>> Mikulas
> 
> 
> Hi
> 
> 
> Lvm2 test suite is creating 'virtual' disk setup - it usually tries 
> first build something with 'brd' - if this device is 'in-use' it 
> fallback to create some files in LVM_TEST_DIR.
> 
> This dir however must allow creation of device - by default nowdays  
> /dev/shm & /tmp are mounted with  'nodev' mount option.
> 
> So a dir which does allow dev creation must be passed to the test - so 
> either remount dir without 'nodev' or set LVM_TEST_DIR to the filesystem 
> which allows creation of devices.

Yes, I know that, and I set LVM_TEST_DIR to a new mounted nvme, as use
can see in the attached log:

[ 0:02.335] ## DF_H:    /dev/nvme0n1     98G   64K   93G   1% /mnt/test

> 
> In 'lvm2/test'   run  'make help'  to see all possible settings - useful 
> one could be LVM_TEST_AUX_TRACE  to expose shell traces from test 
> internals - helps with debugging...
The log do have shell trace, I think, it stoped here, I just don't know
why :(

[ 0:01.709] ## - /root/lvm2/test/shell/lvcreate-large-raid.sh:31
[ 0:01.710] ## 1 STACKTRACE() called from 
/root/lvm2/test/shell/lvcreate-large-raid.sh:31

Thanks,
Kuai

Re: LVM2 test breakage

[Zdenek Kabelac]

Dne 19. 05. 25 v 13:07 Yu Kuai napsal(a):
> Hi,
> 
> 在 2025/05/19 18:45, Zdenek Kabelac 写道:
>> Dne 19. 05. 25 v 12:10 Mikulas Patocka napsal(a):
>>> On Mon, 19 May 2025, Yu Kuai wrote:
>>>
>>>> Hi,
>>>>
>>>> 在 2025/05/19 9:11, Yu Kuai 写道:
>>>>> Hi,
>>>>>
>>>>> 在 2025/05/17 0:00, Mikulas Patocka 写道:
>>>>>> Hi
>>>>>>
>>>>>> The commit e879a0d9cb086c8e52ce6c04e5bfa63825a6213c breaks the test
>>>>>> shell/lvcreate-large-raid.sh in the lvm2 testsuite.
>>>>>>
>>>>>> The breakage is caused by removing the line "read_bio->bi_opf = op |
>>>>>> do_sync;"
>>>>>>
>>>> Do I need some special setup to run this test? I got following
>>>> result in my VM, and I don't understand why it failed.
>>>>
>>>> Ask Zdenek Kabelac - he is expert in the testsuite.
>>>>
>>>> Mikulas
>>
>>
>> Hi
>>
>>
>> Lvm2 test suite is creating 'virtual' disk setup - it usually tries first 
>> build something with 'brd' - if this device is 'in-use' it fallback to 
>> create some files in LVM_TEST_DIR.
>>
>> This dir however must allow creation of device - by default nowdays /dev/shm 
>> & /tmp are mounted with  'nodev' mount option.
>>
>> So a dir which does allow dev creation must be passed to the test - so 
>> either remount dir without 'nodev' or set LVM_TEST_DIR to the filesystem 
>> which allows creation of devices.
> 
> Yes, I know that, and I set LVM_TEST_DIR to a new mounted nvme, as use
> can see in the attached log:
> 
> [ 0:02.335] ## DF_H:    /dev/nvme0n1     98G   64K   93G   1% /mnt/test

Hi

Please  check the output of 'mount' command whether your mount point /mnt/test
allows creation of devices  (i.e. does not use 'nodev' as setting for this 
mountpoint)


> 
>>
>> In 'lvm2/test'   run  'make help'  to see all possible settings - useful one 
>> could be LVM_TEST_AUX_TRACE  to expose shell traces from test internals - 
>> helps with debugging...
> The log do have shell trace, I think, it stoped here, I just don't know
> why :(
> 
> [ 0:01.709] ## - /root/lvm2/test/shell/lvcreate-large-raid.sh:31
> [ 0:01.710] ## 1 STACKTRACE() called from /root/lvm2/test/shell/lvcreate- 
> large-raid.sh:31
> 


Run:

   'make check_local T=lvcreate-large-raid LVM_TEST_AUX_TRACE=1  VERBOSE=1'

for more closer look why it is failing when preparing devices.
My best guess is the use of 'nodev' flag   (thus mount with '-o dev')


Regards

Zdenek

Re: LVM2 test breakage

[Yu Kuai]

Hi,

在 2025/05/19 21:55, Zdenek Kabelac 写道:
> Dne 19. 05. 25 v 13:07 Yu Kuai napsal(a):
>> Hi,
>>
>> 在 2025/05/19 18:45, Zdenek Kabelac 写道:
>>> Dne 19. 05. 25 v 12:10 Mikulas Patocka napsal(a):
>>>> On Mon, 19 May 2025, Yu Kuai wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> 在 2025/05/19 9:11, Yu Kuai 写道:
>>>>>> Hi,
>>>>>>
>>>>>> 在 2025/05/17 0:00, Mikulas Patocka 写道:
>>>>>>> Hi
>>>>>>>
>>>>>>> The commit e879a0d9cb086c8e52ce6c04e5bfa63825a6213c breaks the test
>>>>>>> shell/lvcreate-large-raid.sh in the lvm2 testsuite.
>>>>>>>
>>>>>>> The breakage is caused by removing the line "read_bio->bi_opf = op |
>>>>>>> do_sync;"
>>>>>>>
>>>>> Do I need some special setup to run this test? I got following
>>>>> result in my VM, and I don't understand why it failed.
>>>>>
>>>>> Ask Zdenek Kabelac - he is expert in the testsuite.
>>>>>
>>>>> Mikulas
>>>
>>>
>>> Hi
>>>
>>>
>>> Lvm2 test suite is creating 'virtual' disk setup - it usually tries 
>>> first build something with 'brd' - if this device is 'in-use' it 
>>> fallback to create some files in LVM_TEST_DIR.
>>>
>>> This dir however must allow creation of device - by default nowdays 
>>> /dev/shm & /tmp are mounted with  'nodev' mount option.
>>>
>>> So a dir which does allow dev creation must be passed to the test - 
>>> so either remount dir without 'nodev' or set LVM_TEST_DIR to the 
>>> filesystem which allows creation of devices.
>>
>> Yes, I know that, and I set LVM_TEST_DIR to a new mounted nvme, as use
>> can see in the attached log:
>>
>> [ 0:02.335] ## DF_H:    /dev/nvme0n1     98G   64K   93G   1% /mnt/test
> 
> Hi
> 
> Please  check the output of 'mount' command whether your mount point 
> /mnt/test
> allows creation of devices  (i.e. does not use 'nodev' as setting for 
> this mountpoint)
> 
> 
>>
>>>
>>> In 'lvm2/test'   run  'make help'  to see all possible settings - 
>>> useful one could be LVM_TEST_AUX_TRACE  to expose shell traces from 
>>> test internals - helps with debugging...
>> The log do have shell trace, I think, it stoped here, I just don't know
>> why :(
>>
>> [ 0:01.709] ## - /root/lvm2/test/shell/lvcreate-large-raid.sh:31
>> [ 0:01.710] ## 1 STACKTRACE() called from 
>> /root/lvm2/test/shell/lvcreate- large-raid.sh:31
>>
> 
> 
> Run:
> 
>    'make check_local T=lvcreate-large-raid LVM_TEST_AUX_TRACE=1  VERBOSE=1'
> 
> for more closer look why it is failing when preparing devices.
> My best guess is the use of 'nodev' flag   (thus mount with '-o dev')

nodev is not the cause here, and other tests like lvcreate-large-raid10
can pass. Following is the results after adding LVM_TEST_AUX_TRACE=1
VERBOSE=1:

[ 0:04.201] + local slash
[ 0:04.201] + test -f LOOP
[ 0:04.201] + echo -n '## preparing loop device...'
[ 0:04.201] ## preparing loop device...+ test -f SCSI_DEBUG_DEV
[ 0:04.201] + test '!' -e LOOP
[ 0:04.206] + test -n /mnt/test/LVMTEST4022.LI2unegZz8/dev
[ 0:04.206] + for i in 0 1 2 3 4 5 6 7
[ 0:04.206] + test -e /mnt/test/LVMTEST4022.LI2unegZz8/dev/loop0
[ 0:04.206] + mknod /mnt/test/LVMTEST4022.LI2unegZz8/dev/loop0 b 7 0
[ 0:04.206] + for i in 0 1 2 3 4 5 6 7
[ 0:04.266] + test -e /mnt/test/LVMTEST4022.LI2unegZz8/dev/loop1
[ 0:04.267] + mknod /mnt/test/LVMTEST4022.LI2unegZz8/dev/loop1 b 7 1
[ 0:04.267] + for i in 0 1 2 3 4 5 6 7
[ 0:04.300] + test -e /mnt/test/LVMTEST4022.LI2unegZz8/dev/loop2
[ 0:04.300] + mknod /mnt/test/LVMTEST4022.LI2unegZz8/dev/loop2 b 7 2
[ 0:04.301] + for i in 0 1 2 3 4 5 6 7
[ 0:04.351] + test -e /mnt/test/LVMTEST4022.LI2unegZz8/dev/loop3
[ 0:04.351] + mknod /mnt/test/LVMTEST4022.LI2unegZz8/dev/loop3 b 7 3
[ 0:04.351] + for i in 0 1 2 3 4 5 6 7
[ 0:04.405] + test -e /mnt/test/LVMTEST4022.LI2unegZz8/dev/loop4
[ 0:04.405] + mknod /mnt/test/LVMTEST4022.LI2unegZz8/dev/loop4 b 7 4
[ 0:04.407] + for i in 0 1 2 3 4 5 6 7
[ 0:04.452] + test -e /mnt/test/LVMTEST4022.LI2unegZz8/dev/loop5
[ 0:04.453] + mknod /mnt/test/LVMTEST4022.LI2unegZz8/dev/loop5 b 7 5
[ 0:04.453] + for i in 0 1 2 3 4 5 6 7
[ 0:04.503] + test -e /mnt/test/LVMTEST4022.LI2unegZz8/dev/loop6
[ 0:04.503] + mknod /mnt/test/LVMTEST4022.LI2unegZz8/dev/loop6 b 7 6
[ 0:04.505] + for i in 0 1 2 3 4 5 6 7
[ 0:04.555] + test -e /mnt/test/LVMTEST4022.LI2unegZz8/dev/loop7
[ 0:04.555] + mknod /mnt/test/LVMTEST4022.LI2unegZz8/dev/loop7 b 7 7
[ 0:04.558] + echo -n .
[ 0:04.607] .+ local LOOPFILE=/mnt/test/LVMTEST4022.LI2unegZz8/test.img
[ 0:04.607] + rm -f /mnt/test/LVMTEST4022.LI2unegZz8/test.img 
 
                                                                [ 
0:04.608] + dd if=/dev/zero of=/mnt/test/LVMTEST4022.LI2unegZz8/test.img 
bs=1048576 count=0 seek=5000000003
[ 0:04.650] set +vx; STACKTRACE; set -vx
[ 0:04.702] ##lvcreate-large-raid.sh:31+ set +vx
[ 0:04.703] ## - /root/lvm2/test/shell/lvcreate-large-raid.sh:31
[ 0:04.705] ## 1 STACKTRACE() called from 
/root/lvm2/test/shell/lvcreate-large-raid.sh:31

Then I tried the dd cmd myself:

dd if=/dev/zero of=/mnt/test/test.img bs=1048576 count=0 seek=5000000003
dd: failed to truncate to 5242880003145728 bytes in output file 
'/mnt/test/test.img': File too large

And this is because ext4 has hard limit of file size, 2^48:

fs/ext4/super.c:        sb->s_maxbytes = 
ext4_max_size(sb->s_blocksize_bits, has_huge_files);

So, I can't use ext4 for this testcase. :(

Thanks,
Kuai

> 
> Regards
> 
> Zdenek
> 
> .
> 

Re: LVM2 test breakage

[Yu Kuai]

Hi,

在 2025/05/20 9:45, Yu Kuai 写道:
> dd if=/dev/zero of=/mnt/test/test.img bs=1048576 count=0 seek=5000000003
> dd: failed to truncate to 5242880003145728 bytes in output file 
> '/mnt/test/test.img': File too large
> 
> And this is because ext4 has hard limit of file size, 2^48:
> 
> fs/ext4/super.c:        sb->s_maxbytes = 
> ext4_max_size(sb->s_blocksize_bits, has_huge_files);
> 
> So, I can't use ext4 for this testcase. :(

Sadly, after switching to xfs, with 2^64 file size limit, I got a new
error:

[ 0:10.980] # 200 TiB raid1
[ 0:10.980] lvcreate --type raid1 -m 1 -L 200T -n $lv1 $vg1 --nosync
[ 0:10.980] #lvcreate-large-raid.sh:51+ lvcreate --type raid1 -m 1 -L 
200T -n LV1 LVMTEST1868vg1 --nosync
[ 0:10.980] File descriptor 6 (/dev/pts/0) leaked on lvm invocation. 
Parent PID 1868: bash
[ 0:11.226]   WARNING: New raid1 won't be synchronized. Don't read what 
you didn't write!
[ 0:11.397]   Failed to deactivate LVMTEST1868vg1/LV1_rmeta_0.
[ 0:11.776]   Internal error: Removing still active LV 
LVMTEST1868vg1/LV1_rmeta_0.
[ 0:11.966] /root/lvm2/test/shell/lvcreate-large-raid.sh: line 51:  2071 
Aborted                 (core dumped) lvcreate --type raid1 -m 1 -L 200T 
-n $lv1 $vg1 --nosync
[ 0:14.059] set +vx; STACKTRACE; set -vx
[ 0:14.061] ##lvcreate-large-raid.sh:51+ set +vx
[ 0:14.061] ## - /root/lvm2/test/shell/lvcreate-large-raid.sh:51
[ 0:14.065] ## 1 STACKTRACE() called from 
/root/lvm2/test/shell/lvcreate-large-raid.sh:51

Looks like lvcreate crashed.

Thanks,
Kuai

Re: LVM2 test breakage

[Su Yue]

On Tue 20 May 2025 at 09:53, Yu Kuai <yukuai1@huaweicloud.com> 
wrote:

> Hi,
>
> 在 2025/05/20 9:45, Yu Kuai 写道:
>> dd if=/dev/zero of=/mnt/test/test.img bs=1048576 count=0 
>> seek=5000000003
>> dd: failed to truncate to 5242880003145728 bytes in output file
>> '/mnt/test/test.img': File too large
>> And this is because ext4 has hard limit of file size, 2^48:
>> fs/ext4/super.c:        sb->s_maxbytes = 
>> ext4_max_size(sb->s_blocksize_bits,
>> has_huge_files);
>> So, I can't use ext4 for this testcase. :(
>
> Sadly, after switching to xfs, with 2^64 file size limit, I got 
> a new
> error:
>
> [ 0:10.980] # 200 TiB raid1
> [ 0:10.980] lvcreate --type raid1 -m 1 -L 200T -n $lv1 $vg1 
> --nosync
> [ 0:10.980] #lvcreate-large-raid.sh:51+ lvcreate --type raid1 -m 
> 1 -L 200T -n
> LV1 LVMTEST1868vg1 --nosync
> [ 0:10.980] File descriptor 6 (/dev/pts/0) leaked on lvm 
> invocation. Parent PID
> 1868: bash
> [ 0:11.226]   WARNING: New raid1 won't be synchronized. Don't 
> read what you
> didn't write!
> [ 0:11.397]   Failed to deactivate LVMTEST1868vg1/LV1_rmeta_0.
> [ 0:11.776]   Internal error: Removing still active LV
> LVMTEST1868vg1/LV1_rmeta_0.
> [ 0:11.966] /root/lvm2/test/shell/lvcreate-large-raid.sh: line 
> 51:  2071 Aborted
> (core dumped) lvcreate --type raid1 -m 1 -L 200T -n $lv1 $vg1 
> --nosync
> [ 0:14.059] set +vx; STACKTRACE; set -vx
> [ 0:14.061] ##lvcreate-large-raid.sh:51+ set +vx
> [ 0:14.061] ## - /root/lvm2/test/shell/lvcreate-large-raid.sh:51
> [ 0:14.065] ## 1 STACKTRACE() called from
> /root/lvm2/test/shell/lvcreate-large-raid.sh:51
>
> Looks like lvcreate crashed.
>
Can't reproduce it on v6.15-rc7 and lvm2 HEAD 
37b28216fd029ffe2fac815b16645aeb9d352235:

/dev/vdc on /mnt type xfs 
(rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
make check_local T=shell/lvcreate-large-raid.sh 
LVM_TEST_AUX_TRACE=1  VERBOSE=1 LVM_TEST_DIR=/mnt

What's your kernel and lvm versions?

--
Su
> Thanks,
> Kuai

Re: LVM2 test breakage

[Yu Kuai]

Hi,

在 2025/05/20 11:47, Su Yue 写道:
> On Tue 20 May 2025 at 09:53, Yu Kuai <yukuai1@huaweicloud.com> wrote:
> 
>> Hi,
>>
>> 在 2025/05/20 9:45, Yu Kuai 写道:
>>> dd if=/dev/zero of=/mnt/test/test.img bs=1048576 count=0 seek=5000000003
>>> dd: failed to truncate to 5242880003145728 bytes in output file
>>> '/mnt/test/test.img': File too large
>>> And this is because ext4 has hard limit of file size, 2^48:
>>> fs/ext4/super.c:        sb->s_maxbytes = 
>>> ext4_max_size(sb->s_blocksize_bits,
>>> has_huge_files);
>>> So, I can't use ext4 for this testcase. :(
>>
>> Sadly, after switching to xfs, with 2^64 file size limit, I got a new
>> error:
>>
>> [ 0:10.980] # 200 TiB raid1
>> [ 0:10.980] lvcreate --type raid1 -m 1 -L 200T -n $lv1 $vg1 --nosync
>> [ 0:10.980] #lvcreate-large-raid.sh:51+ lvcreate --type raid1 -m 1 -L 
>> 200T -n
>> LV1 LVMTEST1868vg1 --nosync
>> [ 0:10.980] File descriptor 6 (/dev/pts/0) leaked on lvm invocation. 
>> Parent PID
>> 1868: bash
>> [ 0:11.226]   WARNING: New raid1 won't be synchronized. Don't read 
>> what you
>> didn't write!
>> [ 0:11.397]   Failed to deactivate LVMTEST1868vg1/LV1_rmeta_0.
>> [ 0:11.776]   Internal error: Removing still active LV
>> LVMTEST1868vg1/LV1_rmeta_0.
>> [ 0:11.966] /root/lvm2/test/shell/lvcreate-large-raid.sh: line 51:  
>> 2071 Aborted
>> (core dumped) lvcreate --type raid1 -m 1 -L 200T -n $lv1 $vg1 --nosync
>> [ 0:14.059] set +vx; STACKTRACE; set -vx
>> [ 0:14.061] ##lvcreate-large-raid.sh:51+ set +vx
>> [ 0:14.061] ## - /root/lvm2/test/shell/lvcreate-large-raid.sh:51
>> [ 0:14.065] ## 1 STACKTRACE() called from
>> /root/lvm2/test/shell/lvcreate-large-raid.sh:51
>>
>> Looks like lvcreate crashed.
>>
> Can't reproduce it on v6.15-rc7 and lvm2 HEAD 
> 37b28216fd029ffe2fac815b16645aeb9d352235:
> 
> /dev/vdc on /mnt type xfs 
> (rw,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota)
> make check_local T=shell/lvcreate-large-raid.sh LVM_TEST_AUX_TRACE=1  
> VERBOSE=1 LVM_TEST_DIR=/mnt
> 
> What's your kernel and lvm versions?

Thanks for the notice, I just switched lvm to this commit, make
distclean, and them everything looks fine now. :)

Thanks,
Kuai

> 
> -- 
> Su
>> Thanks,
>> Kuai
> .
> 

Re: LVM2 test breakage

[Mikulas Patocka]

[-- Attachment #1: Type: text/plain, Size: 920 bytes --]



On Mon, 19 May 2025, Yu Kuai wrote:

> Hi,
> 
> 在 2025/05/17 0:00, Mikulas Patocka 写道:
> > Hi
> > 
> > The commit e879a0d9cb086c8e52ce6c04e5bfa63825a6213c breaks the test
> > shell/lvcreate-large-raid.sh in the lvm2 testsuite.
> > 
> > The breakage is caused by removing the line "read_bio->bi_opf = op |
> > do_sync;"
> > 
> 
> Sorry that I don't undertand here, before the patch:
> 
> op = bio_op(bio);
> do_sync = bio->bi_opf & REQ_SYNC;
> read_bio->bi_opf = op | do_sync
> 
> after the patch:
> 
> read_bio = bio_alloc_clone(, bio, ...)
>  read_bio->bi_opf = bio->bi_opf
> 
> So, after the patch, other than bio_op() and REQ_SYNC, other bio flags
> are keeped, I don't see problem for now, I'll run the test later.
> 
> Thanks,
> Kuai

The problem is caused by the REQ_RAHEAD flag - bios with this flag may 
fail anytime. I presume that the bug is caused by raid1 mishandling this 
failure.

Mikulas

[PATCH] md/raid1,raid10: don't pass down the REQ_RAHEAD flag

[Mikulas Patocka]

The commit e879a0d9cb08 ("md/raid1,raid10: don't ignore IO flags") breaks
the lvm2 test shell/lvcreate-large-raid.sh. The commit changes raid1 and
raid10 to pass down all the flags from the incoming bio. The problem is
when we pass down the REQ_RAHEAD flag - bios with this flag may fail
anytime and md-raid is not prepared to handle this failure.

This commit fixes the code, so that the REQ_RAHEAD flag is not passed
down.

Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Fixes: e879a0d9cb08 ("md/raid1,raid10: don't ignore IO flags")

---
 drivers/md/raid1.c  |    1 +
 drivers/md/raid10.c |    1 +
 2 files changed, 2 insertions(+)

Index: linux-2.6/drivers/md/raid1.c
===================================================================
--- linux-2.6.orig/drivers/md/raid1.c
+++ linux-2.6/drivers/md/raid1.c
@@ -1404,6 +1404,7 @@ static void raid1_read_request(struct md
 	read_bio->bi_iter.bi_sector = r1_bio->sector +
 		mirror->rdev->data_offset;
 	read_bio->bi_end_io = raid1_end_read_request;
+	read_bio->bi_opf &= ~REQ_RAHEAD;
 	if (test_bit(FailFast, &mirror->rdev->flags) &&
 	    test_bit(R1BIO_FailFast, &r1_bio->state))
 	        read_bio->bi_opf |= MD_FAILFAST;
Index: linux-2.6/drivers/md/raid10.c
===================================================================
--- linux-2.6.orig/drivers/md/raid10.c
+++ linux-2.6/drivers/md/raid10.c
@@ -1263,6 +1263,7 @@ static void raid10_write_one_disk(struct
 	mbio->bi_iter.bi_sector	= (r10_bio->devs[n_copy].addr +
 				   choose_data_offset(r10_bio, rdev));
 	mbio->bi_end_io	= raid10_end_write_request;
+	mbio->bi_opf &= ~REQ_RAHEAD;
 	if (!replacement && test_bit(FailFast,
 				     &conf->mirrors[devnum].rdev->flags)
 			 && enough(conf, devnum))

Re: [PATCH] md/raid1,raid10: don't pass down the REQ_RAHEAD flag

[Yu Kuai]

Hi,

在 2025/05/19 18:09, Mikulas Patocka 写道:
> The commit e879a0d9cb08 ("md/raid1,raid10: don't ignore IO flags") breaks
> the lvm2 test shell/lvcreate-large-raid.sh. The commit changes raid1 and
> raid10 to pass down all the flags from the incoming bio. The problem is
> when we pass down the REQ_RAHEAD flag - bios with this flag may fail
> anytime and md-raid is not prepared to handle this failure.

Can dm-raid handle this falg? At least from md-raid array, for read
ahead IO, it doesn't make sense to kill that flag.

If we want to fall back to old behavior, can we kill that flag from
dm-raid?

diff --git a/drivers/md/dm-raid.c b/drivers/md/dm-raid.c
index 127138c61be5..ca7fb1713117 100644
--- a/drivers/md/dm-raid.c
+++ b/drivers/md/dm-raid.c
@@ -3353,6 +3353,11 @@ static int raid_map(struct dm_target *ti, struct 
bio *bio)
         if (unlikely(bio_has_data(bio) && bio_end_sector(bio) > 
mddev->array_sectors))
                 return DM_MAPIO_REQUEUE;

+       /*
+        * bios with this flag may fail anytime, dm-raid is not prepared to
+        * handle failure.
+        */
+       bio->bi_opf &= ~REQ_RAHEAD;
         if (unlikely(!md_handle_request(mddev, bio)))
                 return DM_MAPIO_REQUEUE;

Thanks,
Kuai

> 
> This commit fixes the code, so that the REQ_RAHEAD flag is not passed
> down.
> 
> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
> Fixes: e879a0d9cb08 ("md/raid1,raid10: don't ignore IO flags")
> 
> ---
>   drivers/md/raid1.c  |    1 +
>   drivers/md/raid10.c |    1 +
>   2 files changed, 2 insertions(+)
> 
> Index: linux-2.6/drivers/md/raid1.c
> ===================================================================
> --- linux-2.6.orig/drivers/md/raid1.c
> +++ linux-2.6/drivers/md/raid1.c
> @@ -1404,6 +1404,7 @@ static void raid1_read_request(struct md
>   	read_bio->bi_iter.bi_sector = r1_bio->sector +
>   		mirror->rdev->data_offset;
>   	read_bio->bi_end_io = raid1_end_read_request;
> +	read_bio->bi_opf &= ~REQ_RAHEAD;
>   	if (test_bit(FailFast, &mirror->rdev->flags) &&
>   	    test_bit(R1BIO_FailFast, &r1_bio->state))
>   	        read_bio->bi_opf |= MD_FAILFAST;
> Index: linux-2.6/drivers/md/raid10.c
> ===================================================================
> --- linux-2.6.orig/drivers/md/raid10.c
> +++ linux-2.6/drivers/md/raid10.c
> @@ -1263,6 +1263,7 @@ static void raid10_write_one_disk(struct
>   	mbio->bi_iter.bi_sector	= (r10_bio->devs[n_copy].addr +
>   				   choose_data_offset(r10_bio, rdev));
>   	mbio->bi_end_io	= raid10_end_write_request;
> +	mbio->bi_opf &= ~REQ_RAHEAD;
>   	if (!replacement && test_bit(FailFast,
>   				     &conf->mirrors[devnum].rdev->flags)
>   			 && enough(conf, devnum))
> 
> 
> .
> 

Re: [PATCH] md/raid1,raid10: don't pass down the REQ_RAHEAD flag

[Yu Kuai]

Hi,

在 2025/05/19 19:19, Yu Kuai 写道:
>> The commit e879a0d9cb08 ("md/raid1,raid10: don't ignore IO flags") breaks
>> the lvm2 test shell/lvcreate-large-raid.sh. The commit changes raid1 and
>> raid10 to pass down all the flags from the incoming bio. The problem is
>> when we pass down the REQ_RAHEAD flag - bios with this flag may fail
>> anytime and md-raid is not prepared to handle this failure.
> 
> Can dm-raid handle this falg? At least from md-raid array, for read
> ahead IO, it doesn't make sense to kill that flag.
> 
> If we want to fall back to old behavior, can we kill that flag from
> dm-raid?

Please ignore the last reply, I misunderstand your commit message, I
thought you said dm-raid, actually you said mdraid, and it's correct,
if read_bio faild raid1/10 will set badblocks which is not expected.

Then for reada head IO, I still think don't kill REQ_RAHEAD for
underlying disks is better, what do you think about skip handling IO
error for ead ahead IO?

diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
index 657d481525be..b8b4fead31f3 100644
--- a/drivers/md/raid1.c
+++ b/drivers/md/raid1.c
@@ -380,7 +380,10 @@ static void raid1_end_read_request(struct bio *bio)
                 /* This was a fail-fast read so we definitely
                  * want to retry */
                 ;
-       else {
+       else if (bio->bi_opf & REQ_RAHEAD) {
+               /* don't handle readahead error, which can fail at 
anytime. */
+               uptodate = 1;
+       } else {
                 /* If all other devices have failed, we want to return
                  * the error upwards rather than fail the last device.
                  * Here we redefine "uptodate" to mean "Don't want to 
retry"
diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
index dce06bf65016..4d51aaf3b39b 100644
--- a/drivers/md/raid10.c
+++ b/drivers/md/raid10.c
@@ -399,6 +399,9 @@ static void raid10_end_read_request(struct bio *bio)
                  * wait for the 'master' bio.
                  */
                 set_bit(R10BIO_Uptodate, &r10_bio->state);
+       } else if (bio->bi_opf & REQ_RAHEAD) {
+               /* don't handle readahead error, which can fail at 
anytime. */
+               uptodate = 1;
         } else {
                 /* If all other devices that store this block have
                  * failed, we want to return the error upwards rather

Thanks,
Kuai

Re: [PATCH] md/raid1,raid10: don't pass down the REQ_RAHEAD flag

[Mikulas Patocka]

[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]



On Mon, 19 May 2025, Yu Kuai wrote:

> Hi,
> 
> 在 2025/05/19 19:19, Yu Kuai 写道:
> > > The commit e879a0d9cb08 ("md/raid1,raid10: don't ignore IO flags") breaks
> > > the lvm2 test shell/lvcreate-large-raid.sh. The commit changes raid1 and
> > > raid10 to pass down all the flags from the incoming bio. The problem is
> > > when we pass down the REQ_RAHEAD flag - bios with this flag may fail
> > > anytime and md-raid is not prepared to handle this failure.
> > 
> > Can dm-raid handle this falg? At least from md-raid array, for read
> > ahead IO, it doesn't make sense to kill that flag.
> > 
> > If we want to fall back to old behavior, can we kill that flag from
> > dm-raid?
> 
> Please ignore the last reply, I misunderstand your commit message, I
> thought you said dm-raid, actually you said mdraid, and it's correct,
> if read_bio faild raid1/10 will set badblocks which is not expected.
> 
> Then for reada head IO, I still think don't kill REQ_RAHEAD for
> underlying disks is better, what do you think about skip handling IO
> error for ead ahead IO?

I presume that md-raid will report an error and kick the disk out of the 
array if a bio with REQ_RAHEAD fails - could this be the explanation of 
this bug?

Mikulas

Re: [PATCH] md/raid1,raid10: don't pass down the REQ_RAHEAD flag

[Yu Kuai]

Hi,

在 2025/05/19 20:05, Mikulas Patocka 写道:
> 
> 
> On Mon, 19 May 2025, Yu Kuai wrote:
> 
>> Hi,
>>
>> 在 2025/05/19 19:19, Yu Kuai 写道:
>>>> The commit e879a0d9cb08 ("md/raid1,raid10: don't ignore IO flags") breaks
>>>> the lvm2 test shell/lvcreate-large-raid.sh. The commit changes raid1 and
>>>> raid10 to pass down all the flags from the incoming bio. The problem is
>>>> when we pass down the REQ_RAHEAD flag - bios with this flag may fail
>>>> anytime and md-raid is not prepared to handle this failure.
>>>
>>> Can dm-raid handle this falg? At least from md-raid array, for read
>>> ahead IO, it doesn't make sense to kill that flag.
>>>
>>> If we want to fall back to old behavior, can we kill that flag from
>>> dm-raid?
>>
>> Please ignore the last reply, I misunderstand your commit message, I
>> thought you said dm-raid, actually you said mdraid, and it's correct,
>> if read_bio faild raid1/10 will set badblocks which is not expected.
>>
>> Then for reada head IO, I still think don't kill REQ_RAHEAD for
>> underlying disks is better, what do you think about skip handling IO
>> error for ead ahead IO?
> 
> I presume that md-raid will report an error and kick the disk out of the
> array if a bio with REQ_RAHEAD fails - could this be the explanation of
> this bug?

This is right if the rdev is set FailFast. However, by default if bio
failed, raid1/raid10 will record badblocks first, and retry the read
untill all underlying disks faild, then read_balance() will finally
found there is no avaliable disk to read and return error.

BTW, I still need to figure out how to run this test to see what really
happened.

Thanks,
Kuai

> 
> Mikulas
> 

Re: [PATCH] md/raid1,raid10: don't pass down the REQ_RAHEAD flag

[Yu Kuai]

Hi,

在 2025/05/19 20:34, Yu Kuai 写道:
> Hi,
> 
> 在 2025/05/19 20:05, Mikulas Patocka 写道:
>>
>>
>> On Mon, 19 May 2025, Yu Kuai wrote:
>>
>>> Hi,
>>>
>>> 在 2025/05/19 19:19, Yu Kuai 写道:
>>>>> The commit e879a0d9cb08 ("md/raid1,raid10: don't ignore IO flags") 
>>>>> breaks
>>>>> the lvm2 test shell/lvcreate-large-raid.sh. The commit changes 
>>>>> raid1 and
>>>>> raid10 to pass down all the flags from the incoming bio. The 
>>>>> problem is
>>>>> when we pass down the REQ_RAHEAD flag - bios with this flag may fail
>>>>> anytime and md-raid is not prepared to handle this failure.
>>>>
>>>> Can dm-raid handle this falg? At least from md-raid array, for read
>>>> ahead IO, it doesn't make sense to kill that flag.
>>>>
>>>> If we want to fall back to old behavior, can we kill that flag from
>>>> dm-raid?
>>>
>>> Please ignore the last reply, I misunderstand your commit message, I
>>> thought you said dm-raid, actually you said mdraid, and it's correct,
>>> if read_bio faild raid1/10 will set badblocks which is not expected.
>>>
>>> Then for reada head IO, I still think don't kill REQ_RAHEAD for
>>> underlying disks is better, what do you think about skip handling IO
>>> error for ead ahead IO?
>>
>> I presume that md-raid will report an error and kick the disk out of the
>> array if a bio with REQ_RAHEAD fails - could this be the explanation of
>> this bug?
> 
> This is right if the rdev is set FailFast. However, by default if bio
> failed, raid1/raid10 will record badblocks first, and retry the read
> untill all underlying disks faild, then read_balance() will finally
> found there is no avaliable disk to read and return error.
> 
> BTW, I still need to figure out how to run this test to see what really
> happened.

I can run the test now, and I confirmed that the dm-raid is build on the
top of dm-zero, and for dm-zero, all read ahead bio will return -EIO.
And failfast is set, causing test to fail:

[ 0:54.960] [135.521104] <2> 2025-05-20 06:20:23  md/raid1:mdX: Disk 
failure on dm-6, disabling device.\x0amd/raid1:mdX: Operation continuing 
on 1 devices.
[ 0:54.960] #lvcreate-large-raid.sh:77+ check lv_field 
LVMTEST1119vg1/LV1 size 400.00t
[ 0:55.012] File descriptor 6 (/dev/pts/0) leaked on lvm invocation. 
Parent PID 1670: bash
[ 0:55.278] WARNING: RaidLV LVMTEST1119vg1/LV1 needs to be refreshed! 
See character 'r' at position 9 in the RaidLV's attributes and also its 
SubLV(s) with option '-a'.
[ 0:55.307] check raid_leg_status $vg1 $lv1 "AA"
[ 0:55.474] #lvcreate-large-raid.sh:78+ check raid_leg_status 
LVMTEST1119vg1 LV1 AA
[ 0:55.474] LVMTEST1119vg1-LV1 status DA != AA  (0 858993459200 raid 
raid1 2 DA 429496729600/429496729600 idle 0 0 -)
[ 0:55.534] set +vx; STACKTRACE; set -vx

Thanks,
Kuai

> 
> Thanks,
> Kuai
> 
>>
>> Mikulas
>>
> 
> .
> 

Re: [PATCH] md/raid1,raid10: don't pass down the REQ_RAHEAD flag

[Mikulas Patocka]

On Mon, 19 May 2025, Yu Kuai wrote:

> Hi,
> 
> Please ignore the last reply, I misunderstand your commit message, I
> thought you said dm-raid, actually you said mdraid, and it's correct,
> if read_bio faild raid1/10 will set badblocks which is not expected.
> 
> Then for reada head IO, I still think don't kill REQ_RAHEAD for
> underlying disks is better, what do you think about skip handling IO
> error for ead ahead IO?
> 
> diff --git a/drivers/md/raid1.c b/drivers/md/raid1.c
> index 657d481525be..b8b4fead31f3 100644
> --- a/drivers/md/raid1.c
> +++ b/drivers/md/raid1.c
> @@ -380,7 +380,10 @@ static void raid1_end_read_request(struct bio *bio)
>                 /* This was a fail-fast read so we definitely
>                  * want to retry */
>                 ;
> -       else {
> +       else if (bio->bi_opf & REQ_RAHEAD) {
> +               /* don't handle readahead error, which can fail at anytime. */
> +               uptodate = 1;
> +       } else {
>                 /* If all other devices have failed, we want to return
>                  * the error upwards rather than fail the last device.
>                  * Here we redefine "uptodate" to mean "Don't want to retry"
> diff --git a/drivers/md/raid10.c b/drivers/md/raid10.c
> index dce06bf65016..4d51aaf3b39b 100644
> --- a/drivers/md/raid10.c
> +++ b/drivers/md/raid10.c
> @@ -399,6 +399,9 @@ static void raid10_end_read_request(struct bio *bio)
>                  * wait for the 'master' bio.
>                  */
>                 set_bit(R10BIO_Uptodate, &r10_bio->state);
> +       } else if (bio->bi_opf & REQ_RAHEAD) {
> +               /* don't handle readahead error, which can fail at anytime. */
> +               uptodate = 1;
>         } else {
>                 /* If all other devices that store this block have
>                  * failed, we want to return the error upwards rather
> 
> Thanks,
> Kuai

I confirm that this patch fixes the test.

Tested-by: Mikulas Patocka <mpatocka@redhat.com>

Mikulas