[smartmontools-support] [PATCH v7] scsi: Add hwmon support for SMART temperature sensors
linus.walleij at linaro.org
Thu Nov 22 14:49:53 CET 2018
On Wed, Nov 21, 2018 at 6:28 PM Martin K. Petersen
<martin.petersen at oracle.com> wrote:
> The problem with all this is that the storage topology is largely
> undiscoverable for monitoring purposes. We can use heuristics, but in
> many cases there is no reliable way to find out that there is an ATA
> device behind member #3 of a USB-attached RAID controller's virtual disk
OK I guess they just opt out of it?
> You could then argue that the kernel should only provide sensors for a
> trivial subset of configurations such as direct-attached ATA/SAS/USB
> devices that provide sufficient heuristics to ensure we don't
> accidentally send commands down that may wedge the device.
This is what the current patch does ... it's an opt-in per-subsystem.
I just opted in libata PATA devices (pretty obvious this will work)
and USB, and tested a bit with different devices there, nothing seems
to break, the ATA disks behind USB transport works fine and
report temperature just fine.
> I.e. repicate
> smartmontools' heuristics inside the kernel. That's a valid position but
> I remain unconvinced that it's worth it. Do you have specific user cases
> other than this particular RAID box without enclosure sensors?
It is not a RAID box at all. It is a simple NAS with a single disk.
I just slot in a 1 terabyte drive and use as home NAS.
> also worth noting that HDD temperature sensors are notoriously
I am sorry if you think that D-Link does bad engineering, what I
am trying to achieve is upstream support for this device, without
any out-of-tree patches. The D-Link DIR-685 uses the harddisk
sensor for this, whether we like it or not.
> And finally, from an implementation perspective, both James and Doug
> pointed you to SAT and the SCSI Temperature Log Page. libata is our
> SAT. And thus the S.M.A.R.T. bits should be located in a libsmart
> library that libata and USB can use to fill out the SCSI Temperature Log
> Page. The hwmon-facing code would then use that log page instead of
> dissecting S.M.A.R.T. information directly.
I hope this is possible without having to buy and implement
the same mechanism also for SCSI drives. I don't have any
Initially James asked me to move this from libata to
scsi with this argument:
James Bottomley wrote
> Given that you're using scsi_execute and this would work on most SAS
> drives as well as SATA ones, why not use the SAS mode pages and we'll
> translate it to SATA in the existing libata-scsi SAT?
> That way this can work on all SCSI devices that support SMART not just
> the SATA subset.
> If you can't figure out how to do this initially, then simply
> separating smart from libata is a good first start so we can build on
> it in SCSI as well.
So I *think* I went ahead and implemented according to
statement (3) since I have no idea of how to do SAS mode
I did move it over and made subsystems opt into it.
But I can try harder of course!
Douglas Gilbert said:
> Fetch the SCSI Temperature Log page [0xd] with the
> LOG SENSE SCSI command.
> See sat5r01a.pdf chapter 10.3.8 for how that should be translated
> to ATA commands by libata and other SATLs.
Am I right in that the modepages for libata is the stuff inside
drivers/ata/libata-scsi.c, like the stuff on the very top with the
cache_mpage and def_control_mpage?
These are all generated in response to the
ata_scsiop_mode_sense() callback from
ata_scsi_simulate() in response to MODE_SENSE
and MODE_SENSE_10 commands.
As far as I understand, MODE_SENSE is what we
should be using, correct?
I guess I should:
- Add a case for LOG_SENSE (0x4d) in
- Prepare a callback and provide a mode
page 0x0d from there.
- Provide a modepage 0x0d in response to that
command from SCSI.
- Implement some code to request and deal with that
modepage in drivers/scsi to register the hwmon
So what about I try to do that... without a SCSI
device to test it on, just a simulated one through
libata. This will be fun, but I BET the SCSI people
will help me testing it :)
Architecturally I see the upside of this, but I also see
a problem: the modepage simulation would be useful
not only for libata but also (as is proved by testing with
USB cradles) from USB storage as well. But I guess
I can figure that out, it's essentially just a piece of
libata that USB need to share. I can certainly start
with just ATA.
The thing/command I pass in now is ATA_16 (0x85)
16-byte pass-thru, I take it that a ATA_16 pass thru
is NOT a proper command or modepage but
something like an uglyhack?...
More information about the Smartmontools-support