From: "Ewan D. Milne" <emilne@redhat.com>
To: Joe Perches <joe@perches.com>, Daniel Wagner <dwagner@suse.de>,
linux-scsi@vger.kernel.org
Cc: linux-kernel@vger.kernel.org,
"James E.J. Bottomley" <jejb@linux.ibm.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>
Subject: Re: [PATCH] scsi: core: Rate limit "rejecting I/O" messages
Date: Thu, 09 Apr 2020 13:07:05 -0400 [thread overview]
Message-ID: <1b1be267b80404dc8ca5a14b3e26710c53f50fb4.camel@redhat.com> (raw)
In-Reply-To: <2de69a35463317f5eca2ce665b0ee8b90b8c717b.camel@perches.com>
On Wed, 2020-04-08 at 12:49 -0700, Joe Perches wrote:
>
> Could add a ratelimit_state to struct scsi_device.
>
> Something like:
> ---
> drivers/scsi/scsi_scan.c | 2 ++
> include/scsi/scsi_device.h | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
> index f2437a..938c83f 100644
> --- a/drivers/scsi/scsi_scan.c
> +++ b/drivers/scsi/scsi_scan.c
> @@ -279,6 +279,8 @@ static struct scsi_device *scsi_alloc_sdev(struct
> scsi_target *starget,
> scsi_change_queue_depth(sdev, sdev->host->cmd_per_lun ?
> sdev->host->cmd_per_lun : 1);
>
> + ratelimit_state_init(&sdev->rs, DEFAULT_RATELIMIT_INTERVAL,
> + DEFAULT_RATELIMIT_BURST);
> scsi_sysfs_device_initialize(sdev);
>
> if (shost->hostt->slave_alloc) {
> diff --git a/include/scsi/scsi_device.h b/include/scsi/scsi_device.h
> index c3cba2..2600de7 100644
> --- a/include/scsi/scsi_device.h
> +++ b/include/scsi/scsi_device.h
> @@ -8,6 +8,7 @@
> #include <linux/blkdev.h>
> #include <scsi/scsi.h>
> #include <linux/atomic.h>
> +#include <linux/ratelimit.h>
>
> struct device;
> struct request_queue;
> @@ -233,6 +234,7 @@ struct scsi_device {
> struct mutex state_mutex;
> enum scsi_device_state sdev_state;
> struct task_struct *quiesced_by;
> + struct ratelimit_state rs;
> unsigned long sdev_data[];
> } __attribute__((aligned(sizeof(unsigned long))));
>
We could but in our experience this may not work well enough. We do
wants to see the message when the device goes offline, so we can look
at logs from SAN failures to see when that happened, but logging more
than one message per device is worthless. And there can be *LOTS*
of LUNs behind targets that go away. Hundreds. Thousands, even.
I keep getting crash dumps with nothing useful in the dmesg buffer.
And we see a lot of serial console lockups.
-Ewan
next prev parent reply other threads:[~2020-04-09 17:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-08 17:10 Daniel Wagner
2020-04-08 17:36 ` James Bottomley
2020-04-08 19:16 ` Ewan D. Milne
2020-04-08 19:49 ` Joe Perches
2020-04-09 17:07 ` Ewan D. Milne [this message]
2020-04-09 7:36 ` Daniel Wagner
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=1b1be267b80404dc8ca5a14b3e26710c53f50fb4.camel@redhat.com \
--to=emilne@redhat.com \
--cc=dwagner@suse.de \
--cc=jejb@linux.ibm.com \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--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
all inboxes | Powered by JetHome®