lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0be9002bbc7feea0bfd0dc8ad2dccc52bbf34834.camel@linux.ibm.com>
Date:   Wed, 15 Mar 2023 07:48:58 -0400
From:   James Bottomley <jejb@...ux.ibm.com>
To:     Greg KH <gregkh@...uxfoundation.org>,
        "Seymour, Shane M" <shane.seymour@....com>
Cc:     "Martin K. Petersen" <martin.petersen@...cle.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
        "linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>
Subject: Re: [PATCH for-next] scsi: Implement host state statistics

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ