On Thu, 2023-10-26 at 06:50 +0200, Jiri Slaby wrote:
why should we care at all?
My main motivation behind this actually something different. I dislike the fact that we have been statically loading several SCSI modules, always, on every system. It contradicts the concept of loadable modules - if we always load module X, why not make it a built-in in the first place? This change will allow us to cease loading the SCSI modules on every system early during boot, and this makes our distribution a wee little bit leaner, cleaner, and better, IMO. I've wanted to do this for years, and the only reason we haven't done it is that Factory had the scsi modules built-in, and we wanted no difference between Factory and SLE/Leap in this respect.
Using /dev/sd* in fstab is broken for years. So anyone using that should be forced to fix it for good and not find workarounds. Or am I missing something?
Right. It hasn't been actually stable for decades, and this has been communicated extensively. *It's still discouraged to refer to any device by its device node name*. Nothing has changed in this respect. Perhaps the subject I chose for this post was misleading and ill- chosen, sorry for that. I was thinking about the users that had complained previously. The discussion that I linked in my previous post has shown that some TW users have been relying on the ordering, and haven't seen issues until scsi_mod and sd_mod were converted to loadable modules in 6.5.4. I think that our previous assessment of the instability of the /dev/sd* assignments has been incomplete. We used to say that it's caused by asynchronous probing. That's part of the picture, sure, and it matters a lot on large systems with hundreds of LUNs. But on typical small systems, it's not the main factor. What matters there is the ordering in which drivers are loaded, and in which each individual driver probes it's devices. This is the outcome of bsc#1216070. * If sd_mod is loaded before the low-level drivers (ahci and usb- storage on typical workstations), the sd devices will be probed in the order in which the SATA and USB devices appear on their respective buses, providing a certain extent of perceived determinism, because hardware device probing is often done sequentially and takes a couple of milliseconds per device, and the sd device appears instantaneously after the low-level device. * OTOH, if sd_mod is loaded on demand when the first SCSI device matching its modalias is found, there will be a couple of LLD devices already when sd_mod is fully initialized, and the ordering of those will appear to be "random". This is the effect that users have seen with 6.5.4, and I see no reason not to revert it. It's achieved by an innocent "softdep scsi_mod post: sd_mod", and it's hard to perceive a negative impact of this softdep. Systems that have SCSI devices but no SCSI disks are very rare these days. Thanks Martin