linux-hwmon.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
	linux-hwmon@vger.kernel.org, Jean Delvare <jdelvare@suse.com>,
	Linux Doc Mailing List <linux-doc@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	linux-scsi@vger.kernel.org, linux-ide@vger.kernel.org,
	Chris Healy <cphealy@gmail.com>
Subject: Re: [PATCH 1/1] hwmon: Driver for temperature sensors on SATA drives
Date: Mon, 16 Dec 2019 20:20:57 -0800	[thread overview]
Message-ID: <c5689126-46bc-b551-11d7-e5bd8c01f82c@roeck-us.net> (raw)
In-Reply-To: <yq1tv5zhdn5.fsf@oracle.com>

On 12/16/19 6:47 PM, Martin K. Petersen wrote:
> 
> Guenter,
> 
>> Not sure I understand what you mean with 'bazillions of sensors' and
>> 'sensor per scsi_device'. Can you elaborate ? I see one sensor per
>> drive, which is what I would expect.
> 
> Yes, but for storage arrays, hanging off of struct scsi_device means you
> would get a sensor for each volume you create. Even though you
> presumably only have one physical "box" to monitor (ignoring for a
> moment that the drives inside the box may have their own sensors that
> may or may not be visible to the host).
> 
> Also, multi-actuator disk drives are shipping. They present themselves
> to the host as a target with multiple LUNs. Once again you'll probably
> have one temperature sensor for the physical drive but many virtual
> disks being presented to the OS. So you'd end up with for instance 4
> sensors in hwmon even though there physically only is one.
> 
> It's a tough call since there may be hardware configurations where
> distinct per-LUN temperature is valid (some quirky JBODs represent disk
> drives as different LUNs instead of different targets, for instance).
> 
> How expensive will it be to have - say - 100 hwmon sensors instantiated
> for a drive tray?
> 

If that drive tray has 100 physical drives, that is what I would expect
to see. The most expensive part is the device entry, and there are already
several of those for each scsi device. I have seen systems with hundreds
of hwmon devices (backbone switches tend to be quite generous with
voltage, current, power, and temperature sensors), so I am not
particularly concerned in that regard. If there are 100 physical drives,
you would actually want to see the temperature of each drive separately,
as one of them might be overheating due to some internal failure.

If the storage array is represented to the system as single huge physical
drive, which is then split into logical entities not related to physical
drives, I guess that would represent a problem for system management overall.
Maybe such boxes have separate thermal monitoring ? Either case, we
have the question if it is possible to distinguish the pseudo-physical
drive from the virtual drives (or volumes).

I would not mind to tie the hardware monitoring device to something else
than the scsi device if the scsi device does not always have a physical
representation. Is there a way to determine if a scsi device is virtual
or real ? Obviously it does not make sense to report the same temperature
multiple times, and we would want only a single temperature reported
for each physical drive. At the same time, I absolutely want to avoid
a situation where a single hardware monitoring device would report
the temperature of multiple drives. The concern here is crossing OIR
boundaries. A single hardware monitoring device should never cross
an OIR boundary.

Thanks,
Guenter

  reply	other threads:[~2019-12-17  4:21 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-09  5:21 [PATCH 0/1] Summary: hwmon driver for temperature sensors on SATA drives Guenter Roeck
2019-12-09  5:21 ` [PATCH 1/1] hwmon: Driver " Guenter Roeck
2019-12-09  5:28   ` Randy Dunlap
2019-12-09  6:00     ` Guenter Roeck
2019-12-09 17:08   ` Bart Van Assche
2019-12-09 19:20     ` Guenter Roeck
2019-12-10 16:10       ` Bart Van Assche
2019-12-12 22:33   ` Linus Walleij
2019-12-12 23:21     ` Martin K. Petersen
2019-12-13  4:18       ` Guenter Roeck
2019-12-17  2:47         ` Martin K. Petersen
2019-12-17  4:20           ` Guenter Roeck [this message]
2019-12-18  3:39             ` Martin K. Petersen
2019-12-11  4:08 ` [PATCH 0/1] Summary: hwmon driver " Martin K. Petersen
2019-12-11  5:57   ` Guenter Roeck
2019-12-17  2:35     ` Martin K. Petersen
2019-12-17  3:57       ` Guenter Roeck
2019-12-17  5:50         ` Damien Le Moal
2019-12-17 15:47           ` Guenter Roeck
2019-12-18  3:42         ` Martin K. Petersen

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=c5689126-46bc-b551-11d7-e5bd8c01f82c@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=cphealy@gmail.com \
    --cc=jdelvare@suse.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-hwmon@vger.kernel.org \
    --cc=linux-ide@vger.kernel.org \
    --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;
as well as URLs for NNTP newsgroup(s).