From: Simon Kirby <sim@hostway.ca>
To: linux-scsi@vger.kernel.org, linux-block@vger.kernel.org
Subject: Unreliable disk detection order in 5.x
Date: Thu, 4 Nov 2021 23:46:23 -0700 [thread overview]
Message-ID: <20211105064623.GD32560@hostway.ca> (raw)
I'm seeing disk detection order changing across reboots on 5.x kernels
(5.4, 5.10, 5.14), but not 4.9, 4.14, 4.19, with megaraid_sas (Dell
PERC_H700). With 13 disks and 5.14.14, the order changes almost always.
I did initially try to bisect this issue, but it seems to become more
rare in earlier kernels, and there are some non-booting problems between
4.x and 5.x.
The most common effect is swapping of sda with sdb, or two neighboring
devices in the list; for example:
# diff -u lsblk-S-5.10.0 lsblk-S-5.10.0-2
--- lsblk-S-5.10.0 2021-11-04 15:23:23.767008360 -0400
+++ lsblk-S-5.10.0-2 2021-11-04 17:34:37.748310196 -0400
@@ -1,6 +1,6 @@
NAME HCTL TYPE VENDOR MODEL REV TRAN
-sda 0:2:0:0 disk DELL PERC_H700 2.10
-sdb 0:2:2:0 disk DELL PERC_H700 2.10
+sda 0:2:2:0 disk DELL PERC_H700 2.10
+sdb 0:2:0:0 disk DELL PERC_H700 2.10
sdc 0:2:3:0 disk DELL PERC_H700 2.10
sdd 0:2:4:0 disk DELL PERC_H700 2.10
sde 0:2:5:0 disk DELL PERC_H700 2.10
This is happening on vendor (Debian 5.10.0) and home-built kernels, and
on a variety of hosts. On all kernels, the detection printks come up in
an interesting order, but in older kernels, it always ends up with an
sd-name that is ordered by SCSI ID ascending:
[ 2.289776] sd 0:2:0:0: [sda] 999030784 512-byte logical blocks: (512 GB/476 GiB)
[ 2.289918] sd 0:2:4:0: [sdd] 11719933952 512-byte logical blocks: (6.00 TB/5.46 TiB)
[ 2.289947] sd 0:2:3:0: [sdc] 11719933952 512-byte logical blocks: (6.00 TB/5.46 TiB)
[ 2.290032] sd 0:2:6:0: [sdf] 11719933952 512-byte logical blocks: (6.00 TB/5.46 TiB)
[ 2.290210] sd 0:2:7:0: [sdg] 11719933952 512-byte logical blocks: (6.00 TB/5.46 TiB)
[ 2.290248] sd 0:2:9:0: [sdi] 11719933952 512-byte logical blocks: (6.00 TB/5.46 TiB)
[ 2.290323] sd 0:2:2:0: [sdb] 11719933952 512-byte logical blocks: (6.00 TB/5.46 TiB)
[ 2.290461] sd 0:2:5:0: [sde] 11719933952 512-byte logical blocks: (6.00 TB/5.46 TiB)
[ 2.290476] sd 0:2:8:0: [sdh] 11719933952 512-byte logical blocks: (6.00 TB/5.46 TiB)
Full "dmesg" is saved here: https://0x.ca/sim/ref/5.10.0/dmesg
Any ideas on suggestions on what I could use to track down what changed
here, or ideas on what might have influenced it?
Simon-
next reply other threads:[~2021-11-05 7:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-05 6:46 Simon Kirby [this message]
2021-11-05 7:45 ` Unreliable disk detection order in 5.x Damien Le Moal
2021-11-07 2:24 ` Simon Kirby
2021-11-07 19:51 ` Bart Van Assche
2021-11-11 1:01 ` Simon Kirby
2021-11-11 1:16 ` Damien Le Moal
2021-11-11 6:57 ` Hannes Reinecke
2021-11-12 0:11 ` Phillip Susi
2021-11-12 6:38 ` Hannes Reinecke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20211105064623.GD32560@hostway.ca \
--to=sim@hostway.ca \
--cc=linux-block@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.