RE: [PATCH 21/22] scsi: reduce messages for command failure

Elliott, Robert (Server Storage)
2014-09-01T01:15:33Z

> -----Original Message-----
> From: linux-scsi-owner@vger.kernel.org [mailto:linux-scsi-
> owner@vger.kernel.org] On Behalf Of Christoph Hellwig
> Sent: Sunday, 31 August, 2014 5:29 PM
> To: Hannes Reinecke
> Cc: James Bottomley; Ewan Milne; Christoph Hellwig; linux-
> scsi@vger.kernel.org; Hoffmann, Elliot; Yoshihiro Yunomae
> Subject: Re: [PATCH 21/22] scsi: reduce messages for command failure
>
> On Thu, Aug 28, 2014 at 07:33:35PM +0200, Hannes Reinecke wrote:
> > When devices fail they can generate quite a lot of error
> > messages, possibly overloading the logging system.
> > So we should be putting these messages under logging control
> > to be able to silence them if requested.
> > And we should shorten the overall message; more verbose
> > logging can be requested by the normal scsi logging.
>
> While the logging mask magic always confused me I'm fairly sure this
> disables logging the completion errors entirely by default. If that
> was the intention it should be mentioned in the changelog.
>
> I do however think printing them in a ratelimit way might be useful,
> so I'd like to see a few more arguments for not doing it that way if
> you really prefer it.

Before this patch set, ratelimited printing was impossible because
there were so many partial-line printk calls. This patch set
may resolve that problem.

Multiple related lines may still cause problems; if it prints
CDB, sense key, and additional sense code on three lines, you
don't want the CDB and sense key suppressed with the additional
sense code still sneaking out (because command completions
are concurrent).

If those issues can be overcome, then I'd favor offering ratelimited
calls. Maybe the logging level could be used to select the amount,
like:
0 = no prints
1..n = ratelimited versions of the prints
n+1..m = not ratelimited versions of the prints

---
Rob Elliott HP Server Storage