From: Ewan D. Milne on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2504#note_1438567452
I presented about this at LSF/MM in May.
The problem basically is that Bart Van Assche's change to use the driver core
for asynchronous
SCSI disk ("sd") probing had a side effect that resulted in the previously
(mostly) consistent
ordering of minor device number assignments to become unpredictable.
commit f049cf1a7b6737c75884247c3f6383ef104d255a
Author: Bart Van Assche <[email protected]>
Date: Tue Apr 30 14:39:18 2019 -0700
scsi: sd: Rely on the driver core for asynchronous probing
drivers/scsi/sd.c used to assign minor numbers in the synchronous probing
path, and then use its
own asynchronous ("..part2") mechanism to issue the commands to obtain the
device attributes.
Now that everything is asynchronous with the above change, the minor #
assignment is too.
This is causing major problems for our customers.
We had a discussion at LSF/MM, and, as I expected, they rejected doing
anything about this.
Their response was to "use udev". The problem is that the behavior change is
a perceived
longstanding behavior regression in RHEL 9. And there are cases (e.g.
w/virtualization) where
there were implicit expectations about how device numbering would be done.
Also, subsequent
*synchronous* calls to scsi_add_device() e.g. from the mpt3sas driver, do not
result in
ordered minor number assignments, which breaks LSI's functionality.
We do document in the RHEL documentation that customers are supposed to use
persistent device
names (e.g. /dev/by-id/xxx) rather that minor numbers, especially for SAN-
attached devices, but
the unpredictability of minor # (/dev/sda, /dev/sdb) now happens even for
*locally attached disks*.
Hence, the module option to force synchronous probing for people who really
need it.
I do welcome any discussion on the desirability of a RHEL-only change, though.
_______________________________________________
kernel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
