On Thu, Mar 26, 2009 at 07:01:36PM +0000, Bryn M. Reeves wrote:
> On Thu, 2009-03-26 at 14:46 -0400, Konrad Rzeszutek wrote:
> > One of our customers purchased a iSCSI target software that converts the
> > local disks into shareable SAN disks. (http://www.rocketdivision.com/wind.html).
> >
> > Unfortunatly the software exports the vendor/product of the disks the same as
> > on the target. Meaning that the HP LOGICAL DISKS are shown over an iSCSI
> > initiator session. And the cciss_tur checker is kicked off and tries
> > this ioctl call:
> >
> > rc = ioctl(c->fd, CCISS_GETLUNINFO, &lvi);
> > if ( rc != 0) {
> > perror("Error: ");
> > fprintf(stderr, "cciss TUR failed in CCISS_GETLUNINFO: %s\n",
> >
> >
> > which fails, since the ioctl is done on a SCSI device instead
> > on the cciss driver.
> >
> > So should the cciss_tur be modified try to do a normal SCSI tur
> > if it fails to perform the ioctl call? Maybe make a path where
> > it would first do a CCISS_VERSION (not sure if that exists) and
> > if that fail do exactly what the 'tur' checker does?
> >
> > Or maybe (with more of these types of software that turn your box in
> > iSCSI target), provide a means of having a secondary path checker in case
> > the first one fails?
> >
> > Thoughts?
>
> Why not just fix the target to provide more useful vendor/product info
> as the other software targets do?
Sure. I am filling a bug with them. But there isn't anything in the SCSI
specs that mandate this behavior.