On Fri, 2024-04-19 at 15:36 -0400, Laurence Oberman wrote: > On Fri, 2024-04-19 at 14:28 -0500, michael.christie@xxxxxxxxxx wrote: > > On 4/18/24 1:10 PM, Laurence Oberman wrote: > > > Resend of this patch as V2 against Martin's tree. > > > Changes: Removed initialization of global variable > > > storage_quiet_discovery > > > > > > This new parameter storage_quiet_discovery defaults to 0 and > > > behavior is > > > unchanged. If its set to 1 on the kernel line then sd_printk and > > > sdev_printk are disabled for printing. The default logging can be > > > re-enabled any time after boot using /etc/sysctl.conf by setting > > > dev.scsi.storage_quiet_discovery = 0. > > > systctl -w dev.scsi.storage_quiet_discovery=0 will also change it > > > immediately back to logging. i > > > Users can leave it set to 1 on the kernel line and 0 in the conf > > > file > > > so it changes back to default after rc.sysinit. > > > This solves the tough problem of systems with 1000's of > > > storage LUNS consuming a system and preventing it from booting > > > due > > > to > > > NMI's and timeouts due to udev triggers. > > > > > > > I didn't see v1 so maybe this was already asked. Why can you use > > the > > existing SCSI_LOG infrastructure for this? > > > > For example, are the printks that are causing you problems specific > > calls that are not already covered by SCSI_LOG, like the > > sdev_printk > > in > > scsi_probe_lun? Do we just want to have those covered by a new > > SCSI_LOG > > value like SCSI_LOG_DISCOVERY? > > > > > > > > Mike and Bart, Thank you > > I think I looked at this some years back and customers wanted an off > during boot but then on workflow. > I sent the patch a few years back but the problem has not gone away > so > I resent. > > Back Monday after review of your suggestions. > > Regards > Laurence Hello folks OK I remember why I did it this way. (Back in 2021) There are too many places sdev_printk is called, not as bad for sd_printk but still a lot of changes so doing it in the macro was the most sensible. It also masks all the ALUA messages. Adding another KERN_xxx and LOGLEVEL_xxx won't fly and Enterprise customers want the normal log behavior after boot. So I think other than adding a single extra module parameter this solution is the cleanest and makes sense. Using rate_limiting is not what customers want after boot to ensure device logging is back as normal. It's only the boot challenges that cause problems. This change other than adding the single extra option defaults to ZERO changed behavior so I am asking for this please to be considered. It is way too common now for Enterprise customers to have these multi- thousand lun paths and devices. Sincerely Laurence
