[stgt] how to setup a virtual tape using scsi-target-utils?
Rob Evers
revers at redhat.com
Wed Jul 25 23:48:27 CEST 2012
On 07/24/2012 11:44 PM, ronnie sahlberg wrote:
> Rob,
>
> This sounds like a bug in linux kernel/initiator.
>
> scsi: host 14 channel 0 id 0 lun16640 has a LUN larger than allowed by
> the host adapter
>
>
> LUN 16640 is in hex 0x4100 or split into addressing mode and lun
> Addressing mode is 01b and the lun is 100h
>
>
> LUNs are specified as two bytes that is split into two parts.
> The two most significant bits is the addressing mode, and the lower
> 14 bits have a different meaning depending on the mode.
> See SAM for more details.
>
> There are three different ways that luns> 256 can be represented :
> 00b : single lun level structure where the next 6 bits would be
> the bus number, and the lowest 8 bits would be the lun 0-255 on that
> bus.
>
> 11b : extended logical unit addressing, which is very complex and really weird.
>
> Or the one that TGTD uses :
>
> 01b : flat space addressing mode where the low 14 bits are the lun
> number 0-8191
>
>
> So, 0x4100 does not mean lun 16640, it means LUN 256 (using flat
> space addressing mode).
> Seems linux is a little buggy here and should be taught about
> addressing space modes.
>
>
> You could try to change TGTD to use the single lun level structure and
> see if linux can handle that better,
> but that would basically mean that every 256 LUNs, you break off to a
> completely different SCSI bus, and there might be other things that
> start acting up instead.
>
> Best is probably to fix linux so it can handle "flat space addressing
> mode" correctly.
It appears so.
Thanks for the info.
Rob
>
> regards
> ronnie sahlberg
>
>
> On Wed, Jul 25, 2012 at 3:51 AM, Rob Evers<revers at redhat.com> wrote:
>> On 07/16/2012 05:32 PM, ronnie sahlberg wrote:
>>> Can you verify that the tgtd target is running properly ?
>>>
>>>
>>> Just try to start it manually as root as :
>>>
>>> killall -9 tgtd
>>> tgtd
>>>
>>> and verify it is running by netstat -tapn | grep 3260
>>>
>>>
>> Thanks, that worked.
>>
>> I'm currently running into an issue where I try to configure
>> in over 256 virtual tapes via iscsi and on the initiator I see:
>>
>> st 14:0:0:255: Attached scsi tape st254
>> st 14:0:0:255: st254: try direct i/o: yes (alignment 1 B)
>> st 14:0:0:255: Attached scsi generic sg256 type 1
>> scsi: host 14 channel 0 id 0 lun16640 has a LUN larger than allowed by
>> the host adapter
>> scsi: host 14 channel 0 id 0 lun16641 has a LUN larger than allowed by
>> the host adapter
>>
>> Any idea why I would be seeing this?
>>
>> The first 256 (0-255) tape devices look like they are configured
>> into the initiator correctly, and repeating this with the target
>> having 256 tapes appears to work.
>>
>> Looks like is due to the report_luns command not returning
>> the correct data from what I can tell on the host in
>> scsi_report_lun_scan:
>>
>>
>> result = scsi_execute_req(sdev, scsi_cmd, DMA_FROM_DEVICE,
>> lun_data, length,&sshdr,
>> SCSI_TIMEOUT + 4 * HZ, 3, NULL);
>> .
>> .
>> .
>>
>> /*
>> * Scan the luns in lun_data. The entry at offset 0 is really
>> * the header, so start at 1 and go up to and including num_luns.
>> */
>> for (lunp =&lun_data[1]; lunp<=&lun_data[num_luns]; lunp++) {
>> lun = scsilun_to_int(lunp);
>> .
>> .
>> .
>>
>> } else if (lun> sdev->host->max_lun) {
>> printk(KERN_WARNING "scsi: %s lun%d has a LUN
>> larger"
>> " than allowed by the host adapter\n",
>> devname, lun);
>>
>> I poked around a bit and found a fairly stale report of an identical
>> problem:
>>
>> http://old.nabble.com/-PATCH--Allow-more-than-255-LUNs-to-be-reported.-td19448136.html
>>
>>> On Tue, Jul 17, 2012 at 5:25 AM, Rob Evers<revers at redhat.com> wrote:
>>>> On 07/13/2012 07:08 PM, ronnie sahlberg wrote:
>>>>> Hi,
>>>>>
>>>>> If you just want to create a tape drive with a tape loaded, these
>>>>> commands should work :
>>>>>
>>>>> # create a blank tape
>>>>> tgtimg --op new --device-type tape --barcode 12345 --size 100 --type
>>>>> data --file /data/tape001.img
>>>>>
>>>>>
>>>>> # create a target
>>>>> tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.ronnie.test
>>>>>
>>>>> # create a SSC LUN for with the blank tape above loaded into the device
>>>>> tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 1 -b
>>>>> /data/tape001.img --device-type=tape
>>>>>
>>>> I get 'tgtadm: invalid request when trying to create the LU
>>>>
>>>> # tgtimg --op new --device-type tape --barcode 12345 --size 100 --type
>>>> data
>>>> --file /data/tape001.img
>>>> blk_sz: 100, next 1152, 1152
>>>> Sizeof(mam): 1104, sizeof(h): 48
>>>> # tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.ronnie.test
>>>> tgtadm: can't send the request to the tgt daemon, Transport endpoint is
>>>> not
>>>> connected
>>>>
>>>> At this, I did 'service tgtd restart'
>>>>
>>>> # tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.ronnie.test
>>>> # tgtadm --lld iscsi --mode logicalunit --op new --tid 1 --lun 1 -b
>>>> /data/tape001.img --device-type=tape
>>>> tgtadm: invalid request
>>>> #
>>>>
>>>> # tgtimg --help
>>>> Usage: tgtimg [OPTION]
>>>> Linux SCSI Target Framework Image File Utility, version 1.0.24
>>>>
>>>> [root at rhel-storage-03 ~]# tgtadm --help
>>>> Usage: tgtadm [OPTION]
>>>> Linux SCSI Target Framework Administration Utility, version 1.0.24
>>>>
>>>>
>>>> This is all after a fresh reboot.
>>>>
>>>> Am I still missing something?
>>>>
>>>> Rob
>>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe stgt" in
>>> the body of a message to majordomo at vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
More information about the stgt
mailing list