From: James Bottomley <jejb@linux.ibm.com>
To: Greg KH <gregkh@linuxfoundation.org>,
"Seymour, Shane M" <shane.seymour@hpe.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-api@vger.kernel.org" <linux-api@vger.kernel.org>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Subject: Re: [PATCH for-next] scsi: Implement host state statistics
Date: Wed, 15 Mar 2023 07:48:58 -0400 [thread overview]
Message-ID: <0be9002bbc7feea0bfd0dc8ad2dccc52bbf34834.camel@linux.ibm.com> (raw)
In-Reply-To: <ZBFnYwtr+2bfjvcY@kroah.com>
On Wed, 2023-03-15 at 07:36 +0100, Greg KH wrote:
> On Wed, Mar 15, 2023 at 06:08:19AM +0000, Seymour, Shane M wrote:
> > The following patch implements host state statistics via sysfs. The
> > intent is to allow user space to see the state changes and be able
> > to report when a host changes state. The files do not separate out
> > the time spent into each state but only into three:
>
> Why does userspace care about these things at all?
This is the most important question: Why are times spent in various
states and transition counts important? Is this some kind of
predictive failure system, or is it simply logging? If it's logging,
wouldn't you get better information if we output state changes as they
occur then they'd appear as timestamped entries in the syslog from
which all these statistics could be deduced?
> What tool needs them and what can userspace do with the
> information?
> >
[...]
> > A (GPLv2) program called hostmond will be released in a few months
> > that will monitor these interfaces and report (local host only via
> > syslog(3C)) when hosts change state.
>
> We kind of need to see this before the kernel changes can be accepted
> for obvious reasons, what is preventing that from happening now?
I don't think that's a requirement. The whole point of sysfs is it's
user readable, so we don't need a tool to make use of its entries. On
the other hand if this tool can help elucidate the use case for these
statistics, then publishing it now would be useful to help everyone
else understand why this is useful.
James
next prev parent reply other threads:[~2023-03-15 12:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-15 6:08 [PATCH for-next] scsi: Implement host state statistics Seymour, Shane M
2023-03-15 6:36 ` Greg KH
2023-03-15 11:48 ` James Bottomley [this message]
2023-03-16 0:15 ` Seymour, Shane M
2023-03-15 22:41 ` Seymour, Shane M
2023-03-17 16:52 ` Steffen Maier
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=0be9002bbc7feea0bfd0dc8ad2dccc52bbf34834.camel@linux.ibm.com \
--to=jejb@linux.ibm.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=shane.seymour@hpe.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;
as well as URLs for NNTP newsgroup(s).