Re: [PATCH] V2 scsi_mod: Add a new parameter to scsi_mod to control

[Laurence Oberman <loberman@redhat.com>]

On Fri, 2024-04-19 at 14:28 -0500, michael.christie@oracle.com 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