Date: Wed, 13 Jan 2016 13:58:19 -0700 From: Kevin Bowling <kevin.bowling@kev009.com> 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 Message-ID: <CAK7dMtBpjaicTjjHdFEp_iNCrTyMQCr8mFm434T83mACHnOOCA@mail.gmail.com> In-Reply-To: <B9D5C062-145F-4B9C-BCCD-CA8380B7EA2D@panasas.com> References: <80BB5907-CC31-4F06-9C70-E6F7834FF28E@panasas.com> <CAK7dMtBmMdOMs4vdPy0otprfWTVREJCyrVaeVtXj2gw-3BFQGA@mail.gmail.com> <E7955294-60BE-45B9-9197-33767EBD3DEA@panasas.com> <B9D5C062-145F-4B9C-BCCD-CA8380B7EA2D@panasas.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Can you integrate the rotation rate patch in time for 10.3? I'd like to switch saltstack away from using camcontol since at least one person is complaining of machine hangs. Regards, On Mon, Dec 14, 2015 at 8:40 PM, Ravi Pokala <rpokala@mac.com> wrote: > 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?CAK7dMtBpjaicTjjHdFEp_iNCrTyMQCr8mFm434T83mACHnOOCA>