Nick wrote:
> On Sep 30, 8:16 am, Konrad Rzeszutek <[EMAIL PROTECTED]> wrote:
>> On Mon, Sep 29, 2008 at 05:50:17PM -0700, Nick wrote:
>>
>>> On Sep 29, 3:49 pm, Konrad Rzeszutek <[EMAIL PROTECTED]> wrote:
>>>>> Here's the output:
>>>>> [EMAIL PROTECTED] ~]# lsscsi
>>>>> [20:0:0:0]   tape    SEAGATE  ULTRIUM06242-XXX 1613  /dev/st0
>>>>> [21:0:0:0]   mediumx STK      L20              0215  /dev/sch0
>>>>> [22:0:0:0]   tape    SEAGATE  ULTRIUM06242-XXX 1613  /dev/st1
>>>>> As you can see, it does not maintain devids but each one becomes id
>>>>> 0.  As a result, I get the following message when the changer loads:
>>>> Yeah, this is the fault of your storage. It converst the SCSI Ids
>>>> in each seperate target.
>>> I'm not sure what you mean by this being a fault of my storage.  It is
>>> normal for libraries and tape drives to have different SCSI IDs.  I'm
>>> using SCST for the iSCSI Target Server, and that either allows me to
>>> specify all of the SCSI devices under the same target as different
>>> LUNs, or specify them under different targets.  SCST does not allow me
>> Aha! Do it as different LUNs.
>>
>>> to specify the ID the devices are presented as - maybe that's the
>>> fault to which you're referring?
>> I was thinking that it represented them as different targets - which is
>> what you don't want in your case.
> 
> It does allow me to present them as different targets, but it also
> allows me to present them as different LUNs on the same target.  I'm
> not sure why I can't specify different IDs on the same target though -
> that seems like a "missing feature" for SCST.

SCSI ID is purely parallel SCSI concept. Other SCSI transports, 
including iSCSI as well as SAM as a whole, don't have anything like 
that. So, if your tape library application requires use of SCSI IDs and 
can't use LUNs instead, this means that it is limited to work only with 
parallel SCSI libraries. Neither open-iscsi, nor SCST can change it.

> I tried out the
> different LUNs method last night and it seems to be somewhat
> functional, although using the "mtx unload" command doesn't seem to
> trigger an "eject" on the tape drive - I have to run an "mt -f /dev/
> st0 eject" and the do the unload.  Maybe this is normal, but it seems
> like usually you can just do the unload and that will trigger an eject
> on the drive, then move the media.  Anyway, I'll keep playing with
> that...
> 
> -Nick
> > 
> 


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"open-iscsi" group.
To post to this group, send email to open-iscsi@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/open-iscsi
-~----------~----~----~----~------~----~------~--~---

Reply via email to