Re: --bitmap=lockless across server reboot

Hhmm.... I just re-checked it with latest kernel (7.1-rc5) on Fedora
Server 44, and now it works, log below.  I don't remember on which
kernel I saw that issue (7.1-rc3 or 7.1-rc4)

BTW, earlier you mentioned that you are working on raid5 performance
improvements,

"“BTW we're working on performance
improvement for large raid5 arrays for at most 64 disks, results looks great.
However, it might take sometime before we push our work to upstream.”

Are there any progress ?, I'm very interested to test on PCIe 5.0 NVMe drives.

This is Fedora Server 44 (up to date) with compiled kernel 7.1-rc5

[root@qdevice ~]# cat /etc/*release
Fedora release 44 (Forty Four)
NAME="Fedora Linux"
VERSION="44 (Server Edition)"
RELEASE_TYPE=stable
ID=fedora
VERSION_ID=44
VERSION_CODENAME=""
PRETTY_NAME="Fedora Linux 44 (Server Edition)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:44"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f44/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=44
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=44
SUPPORT_END=2027-05-19
VARIANT="Server Edition"
VARIANT_ID=server
Fedora release 44 (Forty Four)
Fedora release 44 (Forty Four)
[root@qdevice ~]#
[root@qdevice ~]# uname -a
Linux qdevice 7.1.0-rc5 #1 SMP PREEMPT_DYNAMIC Mon May 25 15:02:20
EEST 2026 x86_64 GNU/Linux
[root@qdevice ~]#
[root@qdevice mdadm]# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
nvme6n1     259:1    0 447.1G  0 disk
├─nvme6n1p1 259:2    0     1G  0 part /boot/efi
├─nvme6n1p2 259:3    0     1G  0 part /boot
├─nvme6n1p3 259:4    0   220G  0 part /
├─nvme6n1p4 259:5    0     1G  0 part
└─nvme6n1p5 259:6    0   220G  0 part
nvme3n1     259:10   0   2.9T  0 disk
nvme1n1     259:11   0   2.9T  0 disk
nvme0n1     259:12   0   2.9T  0 disk
nvme4n1     259:16   0   2.9T  0 disk
nvme2n1     259:17   0   2.9T  0 disk
nvme5n1     259:18   0   2.9T  0 disk
[root@qdevice mdadm]#
[root@qdevice mdadm]# mdadm --create --verbose /dev/md0 --level=6
--bitmap=lockless --raid-devices=6 /dev/nvme0n1 /dev/nvme1n1
/dev/nvme2n1 /dev/nvme3n1 /dev/nvme4n1 /dev/nvme5n1
mdadm: Experimental lockless bitmap, use at your own risk!
mdadm: layout defaults to left-symmetric
mdadm: layout defaults to left-symmetric
mdadm: chunk size defaults to 512K
mdadm: /dev/nvme0n1 appears to be part of a raid array:
       level=raid6 devices=5 ctime=Wed May 20 12:45:26 2026
mdadm: /dev/nvme1n1 appears to be part of a raid array:
       level=raid6 devices=5 ctime=Wed May 20 12:45:26 2026
mdadm: /dev/nvme2n1 appears to be part of a raid array:
       level=raid6 devices=5 ctime=Wed May 20 12:45:26 2026
mdadm: /dev/nvme3n1 appears to be part of a raid array:
       level=raid6 devices=5 ctime=Wed May 20 12:45:26 2026
mdadm: /dev/nvme4n1 appears to be part of a raid array:
       level=raid6 devices=5 ctime=Wed May 20 12:45:26 2026
mdadm: /dev/nvme5n1 appears to be part of a raid array:
       level=raid6 devices=6 ctime=Wed May 20 11:45:38 2026
mdadm: size set to 3125484544K
Continue creating array [y/N]? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
[root@qdevice mdadm]#
[root@qdevice mdadm]# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme6n1     259:1    0 447.1G  0 disk
├─nvme6n1p1 259:2    0     1G  0 part  /boot/efi
├─nvme6n1p2 259:3    0     1G  0 part  /boot
├─nvme6n1p3 259:4    0   220G  0 part  /
├─nvme6n1p4 259:5    0     1G  0 part
└─nvme6n1p5 259:6    0   220G  0 part
nvme3n1     259:10   0   2.9T  0 disk
└─md0         9:0    0  11.6T  0 raid6
nvme1n1     259:11   0   2.9T  0 disk
└─md0         9:0    0  11.6T  0 raid6
nvme0n1     259:12   0   2.9T  0 disk
└─md0         9:0    0  11.6T  0 raid6
nvme4n1     259:16   0   2.9T  0 disk
└─md0         9:0    0  11.6T  0 raid6
nvme2n1     259:17   0   2.9T  0 disk
└─md0         9:0    0  11.6T  0 raid6
nvme5n1     259:18   0   2.9T  0 disk
└─md0         9:0    0  11.6T  0 raid6
[root@qdevice mdadm]#
[root@qdevice mdadm]# reboot
[root@qdevice mdadm]#

After reboot,

[root@qdevice ~]# lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme6n1     259:1    0 447.1G  0 disk
├─nvme6n1p1 259:2    0     1G  0 part  /boot/efi
├─nvme6n1p2 259:3    0     1G  0 part  /boot
├─nvme6n1p3 259:4    0   220G  0 part  /
├─nvme6n1p4 259:5    0     1G  0 part
└─nvme6n1p5 259:6    0   220G  0 part
nvme2n1     259:9    0   2.9T  0 disk
└─md0         9:0    0  11.6T  0 raid6
nvme1n1     259:10   0   2.9T  0 disk
└─md0         9:0    0  11.6T  0 raid6
nvme4n1     259:15   0   2.9T  0 disk
└─md0         9:0    0  11.6T  0 raid6
nvme0n1     259:16   0   2.9T  0 disk
└─md0         9:0    0  11.6T  0 raid6
nvme3n1     259:17   0   2.9T  0 disk
└─md0         9:0    0  11.6T  0 raid6
nvme5n1     259:18   0   2.9T  0 disk
└─md0         9:0    0  11.6T  0 raid6
[root@qdevice ~]#


Anton

пн, 25 мая 2026 г. в 08:32, Yu Kuai <[email protected]>:
>
> Hi,
>
> 在 2026/5/20 1:28, Anton Gavriliuk 写道:
> > Hi
> >
> > Does md-raid lockless bitmap support server's reboot ?
>
> Yes, of course it should support reboot.
>
> >
> > I don't see md-raid6 created with --bitmap=lockless after reboot.
>
> Do you check kernel log if there is any failure log? And do you try
> mdadm -a manually?
>
> BTW, pPlease report with your environment and test script in details,
> especially kernel version and mdadm version.
>
> >
> > Anton
> >
> --
> Thansk,
> Kuai