Linux SCSI subsystem development
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Laurence Oberman <loberman@redhat.com>,
	martin.petersen@oracle.com, linux-scsi@vger.kernel.org,
	emilne@redhat.com, jpittman@redhat.com, jmeneghi@redhat.com,
	Bart.VanAssche@wdc.com
Subject: Re: [PATCH] V2 scsi_mod: Add a new parameter to scsi_mod to control
Date: Fri, 19 Apr 2024 11:16:18 -0700	[thread overview]
Message-ID: <de973d50-8f57-49ce-9a66-cc1f0570ea2e@acm.org> (raw)
In-Reply-To: <20240418181038.198242-1-loberman@redhat.com>

On 4/18/24 11:10, Laurence Oberman wrote:
> 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.

Are there any alternatives to introducing a new kernel module parameter?
Has it e.g. been considered to rate-limit the messages related to newly
discovered logical units? How about reporting information about new
logical units only if less than ten logical units are discovered per
second?

Thanks,

Bart.


  parent reply	other threads:[~2024-04-19 18:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-18 18:10 [PATCH] V2 scsi_mod: Add a new parameter to scsi_mod to control Laurence Oberman
2024-04-19  0:54 ` Laurence Oberman
2024-04-19 18:16 ` Bart Van Assche [this message]
2024-04-19 19:28 ` michael.christie
2024-04-19 19:36   ` Laurence Oberman
2024-04-21 22:13     ` Laurence Oberman

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=de973d50-8f57-49ce-9a66-cc1f0570ea2e@acm.org \
    --to=bvanassche@acm.org \
    --cc=Bart.VanAssche@wdc.com \
    --cc=emilne@redhat.com \
    --cc=jmeneghi@redhat.com \
    --cc=jpittman@redhat.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=loberman@redhat.com \
    --cc=martin.petersen@oracle.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox