mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Milan P. Gandhi" <mgandhi@redhat.com>
To: Martin Wilck <mwilck@suse.de>,
	Laurence Oberman <loberman@redhat.com>,
	linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Cc: jejb@linux.ibm.com, martin.petersen@oracle.com
Subject: Re: [PATCH] scsi: core: Log SCSI command age with errors
Date: Mon, 30 Sep 2019 14:35:45 +0530	[thread overview]
Message-ID: <31eb5bb6-ca4e-1c6c-3013-7d94ff49623d@redhat.com> (raw)
In-Reply-To: <f2c97e860f895613ba81b69c962660b0c712723a.camel@suse.de>

On 9/30/19 2:12 PM, Martin Wilck wrote:
> On Fri, 2019-09-27 at 13:45 -0400, Laurence Oberman wrote:
>>
>> Hi Martin
>>
>> Agreed about log extraction, but turning that on with a busy workload
>> in a production environment is not practical. We cant do it with
>> systems with 1000's of luns and 1000's of IOPS/sec.
>> Also second resolution is good enough for the debug we want to see.
> 
> I gather that you look at a specific problem where second resolution is
> sufficient. For upstream, the generic usefulness should be considered,
> and I don't think we can say today that better-than-second resolution
> will never be useful, so I still vote for milliseconds.

Ok, I will change it to ms.

> Wrt the enablement of the option on highly loaded systems, I'm not sure
> I understand. You need to enable SCSI logging anyway, don't you?

By default we keep the SCSI debug logging disabled or am I missing 
something?

>Is it an issue to have to set 2 sysfs values rather than just one?

The idea here is to capture the above debug data even without 
any user interventions to change any sysfs entries or to enable 
debug logging on busy, critical production systems.

Also, we are not changing the existing text in SCSI command error log,
but we are only adding one single word at the end of message. Ideally
the user scripts are written to grep specific pattern from the logs.
Since we are not replacing any existing text from the logs, the 
scripts should still work with this change as well.

Thanks,
Milan.

  reply	other threads:[~2019-09-30  9:05 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-23  6:01 Milan P. Gandhi
2019-09-23 13:02 ` Laurence Oberman
2019-09-23 13:24   ` Milan P. Gandhi
2019-09-25 15:45 ` Bart Van Assche
2019-09-26  5:01   ` Milan P. Gandhi
2019-09-27 15:26 ` Martin Wilck
2019-09-27 17:45   ` Laurence Oberman
2019-09-30  8:42     ` Martin Wilck
2019-09-30  9:05       ` Milan P. Gandhi [this message]
2019-09-30  9:46         ` Martin Wilck

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=31eb5bb6-ca4e-1c6c-3013-7d94ff49623d@redhat.com \
    --to=mgandhi@redhat.com \
    --cc=jejb@linux.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=loberman@redhat.com \
    --cc=martin.petersen@oracle.com \
    --cc=mwilck@suse.de \
    /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®