On Wed, Nov 21, 2018 at 6:28 PM Martin K. Petersen <martin.petersen@xxxxxxxxxx> 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 > #5. 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. > (It's > also worth noting that HDD temperature sensors are notoriously > unreliable). 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 SCSI devices... 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 pages 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 ata_scsi_simulate() - 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 sensor 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?... Yours, Linus Walleij
