Accessing static drive info w/o ATA identify and lockup with camcontrol identify

[Ravi Pokala]

Does anyone have any thoughts about this? If not, then I'll code up a patch and throw it on Phabricator.

-Ravi

-----Original Message-----


From: Ravi Pokala <rpokala at panasas.com>
Date: 2015-12-10, Thursday at 08:10
To: Kevin Bowling <kevin.bowling at kev009.com>, Ravi Pokala <rpokala at mac.com>
Cc: "freebsd-scsi at freebsd.org" <freebsd-scsi at freebsd.org>, Sean Bruno <sbruno at freebsd.org>
Subject: Re: Accessing static drive info w/o ATA identify and lockup with camcontrol identify

>-----Original Message-----
>
>From: Kevin Bowling <kevin.bowling at kev009.com>
>Date: 2015-12-10, Thursday at 04:58
>To: Ravi Pokala <rpokala at mac.com>
>Cc: "freebsd-scsi at freebsd.org" <freebsd-scsi at freebsd.org>, Sean Bruno <sbruno at freebsd.org>
>Subject: Re: Accessing static drive info w/o ATA identify and lockup with camcontrol identify
>
>>Thanks Ravi!
>>
>>Rotation rate is probably the most important thing and thankfully easy as you suggested:
>>
>>https://reviews.freebsd.org/D4483.  Would be nice to land that in 10.3 so I can swap the SaltStack module over to it.
>
>As I just commented there, I was actually going to look at this this weekend. My concern is that the d_rotation_rate does not strictly map to the actual rotation rate - there are some special cases and reserved values. I was thinking something more like this:
>
>    sbuf_printf(sb, "%s<rotationrate>", indent);
>    if (dp->d_rotatation_rate == 0)
>        sbuf_printf(sb, "unknown");
>    else if (dp->d_rotation_rate == 1)
>        sbuf_printf(sb, "0");
>    else if ((dp->d_rotation_rate >= 0x041) && (dp->d_rotation_rate <= 0xfffe))
>        sbuf_printf(sb, "%u", dp->d_rotation_rate);
>    else
>        sbuf_printf(sb, "invalid");
>    sbuf_printf(sb, "</rotationrate>\n");
>
>
>That would be more accurate, but slightly harder to parse (depending on what's parsing the XML). I don't have a strong feeling about this; what do other people think? Should it just return the value provided by the drive, or should it do some interpretation?
>
>>Next in priority would be getting firmware version..
>>
>>In 'camcontrol identify' it looks like:  'firmware revision     DXM9203Q'
>>
>>In 'camcontrol inquiry' it's part of the device string like: 'pass0: <SAMSUNG MZ7WD480HCGM-00003 DXM9203Q> ACS-2 ATA SATA 3.x device'
>>
>>Do you have any suggestions for wiring that into geom disk?
>
>Interesting. I never noticed that firmware wasn't already included in "struct disk", like drive model and serial number already are. It should be trivial to add, but keeping a copy of the string will of course make "struct disk" larger. That might have implications on KBI compatibility for out-of-tree drivers...? Again, I'm not sure.
>
>
>>And lastly, yes bus speeds would be nice (especially to spot hard/soft misconfiguration).  It shows up like 'protocol              ATA/ATAPI-9 SATA 3.x' in camcontrol identify and can be seen in the inquiry string above too.  Do you have design suggestions on that?
>
>I'm sure the string that's generated by CAM at attach-time could be preserved. Again, there's the memory and KBI issues of adding another string to "struct disk".
>
>-Ravi