Bug 218866
Summary: | Extra /dev/sd.. entries for a fake raid when more than 15 partitions | ||
---|---|---|---|
Product: | IO/Storage | Reporter: | Marc Debruyne (marc_debruyne) |
Component: | MD | Assignee: | linux-scsi (linux-scsi) |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | marc_debruyne, mkp, phill |
Priority: | P3 | ||
Hardware: | Intel | ||
OS: | Linux | ||
Kernel Version: | 6.9.1 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: | dmesg |
Description
Marc Debruyne
2024-05-21 09:22:50 UTC
Upgraded kernel to 6.9.1-gentoo-x86_64 (6.9.1) same result. Created attachment 306323 [details]
dmesg
dmesg contains:
[ 32.827175] /dev/sde20: Can't open blockdev
[ 32.846921] /dev/sde19: Can't open blockdev
[ 32.878496] ntfs3: Max link count 4000
[ 32.878839] /dev/sde17: Can't open blockdev
[ 32.884543] /dev/sdd20: Can't open blockdev
[ 32.905281] /dev/sdd19: Can't open blockdev
[ 32.922129] /dev/sdd17: Can't open blockdev
Is this a regression. IOW: is this something that did not happen with say 6.6.y or 6.7.y? And are you using a vanilla kernel? Or something close to it? Looks like the partition table is invalid: [ 3.037149] GPT:Primary header thinks Alt. header is not at the end of the disk. [ 3.037151] GPT:1951170559 != 1953525167 [ 3.037153] GPT:Alternate GPT header not at the end of the disk. [ 3.037154] GPT:1951170559 != 1953525167 [ 3.037156] GPT: Use GNU Parted to correct GPT errors. [ 3.037168] sdd: sdd1 sdd2 sdd3 sdd4 sdd5 sdd6 sdd7 sdd8 sdd9 sdd10 sdd11 sdd12 sdd13 sdd14 sdd15 sdd16 sdd17 sdd18 sdd19 sdd20 [ 3.037441] GPT:Primary header thinks Alt. header is not at the end of the disk. [ 3.037443] GPT:1951170559 != 1953525167 [ 3.037445] GPT:Alternate GPT header not at the end of the disk. [ 3.037446] GPT:1951170559 != 1953525167 [ 3.037448] GPT: Use GNU Parted to correct GPT errors. [ 3.037459] sde: sde1 sde2 sde3 sde4 sde5 sde6 sde7 sde8 sde9 sde10 sde11 sde12 sde13 sde14 sde15 sde16 sde17 sde18 sde19 sde20 (In reply to The Linux kernel's regression tracker (Thorsten Leemhuis) from comment #3) > Is this a regression. IOW: is this something that did not happen with say > 6.6.y or 6.7.y? And are you using a vanilla kernel? Or something close The Gentoo kernels are very close to a vanilla kernel. On my Linux from Scratch on another partition on same system with a vanilla 6.4.12 kernel same is occurring. On Ubuntu 22.04 also on same system with kernel 6.2.0-33: same I will compile a kernel 6.6.30 and post result. (In reply to Martin K. Petersen from comment #4) > Looks like the partition table is invalid: > > [ 3.037149] GPT:Primary header thinks Alt. header is not at the end of > the disk. > [ 3.037151] GPT:1951170559 != 1953525167 > [ 3.037153] GPT:Alternate GPT header not at the end of the disk. > [ 3.037154] GPT:1951170559 != 1953525167 > [ 3.037156] GPT: Use GNU Parted to correct GPT errors. > [ 3.037168] sdd: sdd1 sdd2 sdd3 sdd4 sdd5 sdd6 sdd7 sdd8 sdd9 sdd10 > sdd11 sdd12 sdd13 sdd14 sdd15 sdd16 sdd17 sdd18 sdd19 sdd20 > [ 3.037441] GPT:Primary header thinks Alt. header is not at the end of > the disk. > [ 3.037443] GPT:1951170559 != 1953525167 > [ 3.037445] GPT:Alternate GPT header not at the end of the disk. > [ 3.037446] GPT:1951170559 != 1953525167 > [ 3.037448] GPT: Use GNU Parted to correct GPT errors. > [ 3.037459] sde: sde1 sde2 sde3 sde4 sde5 sde6 sde7 sde8 sde9 sde10 > sde11 sde12 sde13 sde14 sde15 sde16 sde17 sde18 sde19 sde20 /dev/ssd and /dev/sde are members of a raid 1 array. This array is a fake raid. It's a LSI Software RAID witch is standard available on the ASUS Z10PE-D16 WS motherboard. The firmware uses the end part of the disk. Note that the partitions 1 to 15 do not have this problem. The partitions 16 to 20 contain a windows 11 system and 2 LFS systems which are fully operational. (In Windows only the raid partitions are visible). Had to install kernel 6.6.21 on an old gentoo partition on same raid array. Same result. So we can assume there is no regression. Maybe it is the first time that someone uses so many partitions on a fake raid. on https://docs.kernel.org/admin-guide/devices.html ************************************************************************ 8 block SCSI disk devices (0-15) 0 = /dev/sda First SCSI disk whole disk 16 = /dev/sdb Second SCSI disk whole disk 32 = /dev/sdc Third SCSI disk whole disk ... 240 = /dev/sdp Sixteenth SCSI disk whole disk Partitions are handled in the same way as for IDE disks (see major number 3) except that the limit on partitions is 15. ************************************************************************ Is the number of partitions really limited to 15 partitions? Surprisingly the extra /dev/ entries start from 16 This is no bug. Fake raids are, well, fake. The kernel sees both individual disks and since they are mirror images of each other, both have the same partitions on them. The dmraid utility can be used to recognize the fake raid metadata and configure the kernel device mapper to access the raid, and with the -Z switch, it will remove the partitions from the underlying individual disks from the kernel's view. Changed "Component" to MD (In reply to Phillip Susi from comment #9) > This is no bug. Fake raids are, well, fake. The kernel sees both > individual disks and since they are mirror images of each other, both have > the same partitions on them. > > The dmraid utility can be used to recognize the fake raid metadata and > configure the kernel device mapper to access the raid, and with the -Z > switch, it will remove the partitions from the underlying individual disks > from the kernel's view. dmraid is not used; mdadm is used ******************** cat /proc/mdstat -------- Personalities : [raid1] [raid6] [raid5] [raid4] md125 : active raid5 sdh1[4] sdb1[2] sdi1[6] sda1[0] sdc1[1] sdf1[3] 87890972160 blocks super 1.2 level 5, 512k chunk, algorithm 2 [6/6] [UUUUUU] bitmap: 5/131 pages [20KB], 65536KB chunk md126 : active raid1 sde[1] sdd[0] 975585280 blocks super external:/md127/0 [2/2] [UU] md127 : inactive sde[1](S) sdd[0](S) 2354608 blocks super external:ddf unused devices: <none> (In reply to Marc Debruyne from comment #11) > dmraid is not used; mdadm is used Ahh yes, they did add support for the Intel fake raids to mdadm. In that case, mdadm needs to learn to remove the partitions from the underlying disk, but that's a user space issue, not in the kernel. |