[dm-devel] hwtable.c for HP LOGICAL VOLUME (cciss_tur isn't working on iSCSI connection).

Konrad Rzeszutek konrad at virtualiron.com
Thu Mar 26 19:29:27 UTC 2009


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.




More information about the dm-devel mailing list