Date: Mon, 14 Dec 2015 19:40:39 -0800 From: Ravi Pokala <rpokala@mac.com> To: Kevin Bowling <kevin.bowling@kev009.com> Cc: "freebsd-scsi@freebsd.org" <freebsd-scsi@freebsd.org>, Sean Bruno <sbruno@freebsd.org> Subject: Re: Accessing static drive info w/o ATA identify and lockup with camcontrol identify Message-ID: <B9D5C062-145F-4B9C-BCCD-CA8380B7EA2D@panasas.com> In-Reply-To: <E7955294-60BE-45B9-9197-33767EBD3DEA@panasas.com> References: <80BB5907-CC31-4F06-9C70-E6F7834FF28E@panasas.com> <CAK7dMtBmMdOMs4vdPy0otprfWTVREJCyrVaeVtXj2gw-3BFQGA@mail.gmail.com> <E7955294-60BE-45B9-9197-33767EBD3DEA@panasas.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@panasas.com> Date: 2015-12-10, Thursday at 08:10 To: Kevin Bowling <kevin.bowling@kev009.com>, Ravi Pokala <rpokala@mac.com> Cc: "freebsd-scsi@freebsd.org" <freebsd-scsi@freebsd.org>, Sean Bruno <sbruno@freebsd.org> Subject: Re: Accessing static drive info w/o ATA identify and lockup with camcontrol identify >-----Original Message----- > >From: Kevin Bowling <kevin.bowling@kev009.com> >Date: 2015-12-10, Thursday at 04:58 >To: Ravi Pokala <rpokala@mac.com> >Cc: "freebsd-scsi@freebsd.org" <freebsd-scsi@freebsd.org>, Sean Bruno <sbruno@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B9D5C062-145F-4B9C-BCCD-CA8380B7EA2D>