Dear Maintainer,

exporting a local SCSI tape drive using targetcli is not possible. The used
SCSI tape
drive is an older HP Ultrium-2 SCSI drive connected via a Adaptec 29320ALP U320
PCIe
SCSI controller to the host.  The host is a freshly set up Debian 9.2 system.

# lscpi -v

03:04.0 SCSI storage controller: Adaptec ASC-29320ALP U320 (rev 10)
        Subsystem: Adaptec ASC-29320LPE PCIe U320
        Flags: bus master, 66MHz, slow devsel, latency 64, IRQ 17
        I/O ports at a800 [disabled] [size=256]
        Memory at fe6fe000 (64-bit, non-prefetchable) [size=8K]
        I/O ports at a400 [disabled] [size=256]
        Expansion ROM at fe600000 [disabled] [size=512K]
        Capabilities: <access denied>
        Kernel driver in use: aic79xx
        Kernel modules: aic79xx

# lscsi -g

[0:0:0:0]    cd/dvd  PLEXTOR  DVD-ROM PX-130A  1.02  /dev/sr0   /dev/sg2
[2:0:0:0]    tape    HP       Ultrium 2-SCSI   F63D  /dev/st0   /dev/sg0
[3:0:0:0]    disk    ATA      Samsung SSD 850  2B6Q  /dev/sdb   /dev/sg3
[4:0:0:0]    disk    ATA      HGST HTS725050A7 B550  /dev/sdc   /dev/sg4
[4:0:1:0]    cd/dvd  HL-DT-ST BD-RE  BH16NS40  1.03  /dev/sr1   /dev/sg5

# uname -a
Linux zahadum 4.9.0-4-amd64 #1 SMP Debian 4.9.51-1 (2017-09-28) x86_64
GNU/Linux

# targetcli

targetcli shell version 2.1.fb43
Copyright 2011-2013 by Datera, Inc and others.
For help on commands, type 'help'.

/> ls
o- /
................................................................................
[...]
  o- backstores
..................................................................... [...]
  | o- block ......................................................... [Storage
Objects: 0]
  | o- fileio ........................................................ [Storage
Objects: 0]
  | o- pscsi ......................................................... [Storage
Objects: 0]
  | o- ramdisk ....................................................... [Storage
Objects: 0]
  o- iscsi ...................................................................
[Targets: 0]
  o- loopback ................................................................
[Targets: 0]
  o- sbp .....................................................................
[Targets: 0]
  o- vhost ...................................................................
[Targets: 0]
/> cd backstores/pscsi
/backstores/pscsi> ls
o- pscsi ............................................................. [Storage
Objects: 0]

/backstores/pscsi> create ultrium2 dev=/dev/st0
Cannot find SCSI device by path, and dev parameter not in H:C:T:L format:
/dev/st0

/backstores/pscsi> create ultrium2 dev=/dev/sg0
Cannot find SCSI device by path, and dev parameter not in H:C:T:L format:
/dev/sg0

/backstores/pscsi> create ultrium2 dev=2:0:0:0
SCSI device does not exist

/backstores/pscsi> create name=test dev=/dev/sr0
Note: block backstore recommended for SCSI block devices
Created pscsi storage object test using /dev/sr0

/backstores/pscsi> ls
o- pscsi ............................................................. [Storage
Objects: 1]
  o- test .......................................................... [/dev/sr0
deactivated]

####

There is no way to correctly specify the tape drive which should be used for
the target.
Note that the test-wise block device export above did work, only the tape can't
be used.

Do you have any further instructions how I can help to determine the cause of
the issue?

Best regards,
Herbert Nachtnebel

Hi,

Thanks for the detailed bug report! Unfortunately I don't have a SCSI
tape drive with which I can test this (I only have disks and CD drives,
which do work according to your report), so I can't reproduce this
myself.

That said, I've looked at the code, and the current pscsi interface
in the targetcli GUI can only export block devices, but tape drives
are actually character devices - that's why it doesn't find anything,
because it looks for devices in /sys/block in the sysfs structure, and
the tape drive doesn't exist there.

Now I'm not currently sure whether this is just a but in targetcli
because it assumes block devices and that tape device export would
actually work on the kernel side, or if this also has problems with
the kernel.

Could you perhaps try to add this manually via the configfs interface?

1. Ensure that rtslib-fb-targetctl.service is started. (To make sure
   the configfs filesystem for LIO is mounted.)

2. Run the following commands to try to create the backstore manually:

# Create backstore ('tape' is just the name here, you can also call
# it something else if you like; the other part of the path is fixed
# though)
mkdir -p /sys/kernel/config/target/core/pscsi_0/tape

# Generate a unique WWN
uuidgen > /sys/kernel/config/target/core/pscsi_0/tape/wwn/vpd_unit_serial

# Add the device (IDs taken from your lsscsi output)
echo scsi_host_id=2,scsi_channel_id=0,scsi_target_id=0,scsi_lun_id=0 \
     > /sys/kernel/config/target/core/pscsi_0/tape/control

# Enable the backstore
echo 1 > /sys/kernel/config/target/core/pscsi_0/tape/enable

# Check kernel logs
# Check 'targetcli ls' output

If that works and the device is added you _should_ be able to export
it via targetcli. If that also works you should be able to use the
tape device from an iSCSI initiator.

What most likely won't work is targetctl being able to reload the
configuration when the system reboots, so this is only temporary. [1]

But if the export of the device actually does work on your system I
could create a patch for targetctl (and possibly targetcli) that
should fix this, and if that does work I'll ask the release team
whether I can get that into the next point release of Stretch.

Regards,
Christian

[1] Note: targetctl is the command used to restore configuration at
    boot, targetcli is the shell to configure it.

Hi Christian!

Thank you very much for the walk through to create the device! Indeed,
with these instruction I could create a backend for the target. For
completeness, one further step was missing: setting the udev_path before
enabling the device:

echo /dev/nst0 > /sys/kernel/config/target/core/pscsi_0/tape/udev_path

But unfortunately, I currently have no time to make functional tests
which will have to wait for today's evening. Stay tuned...

Best regards,
Herbert.


Am 2017-11-05 um 20:42 schrieb Christian Seiler:

Hi there,

Oh, I believed that was optional, that's why I didn't mention
it... ;-)

But great to hear that this just appears to be a problem with the
user space tooling and not the kernel itself - that makes it quite
a bit easier to fix.

Anyway, great that that appears to work, and I'll wait for your
functional tests. If those do work out (i.e. you can use that device
from an initiator) I'll work on a patch for the targetcli command.

Regards,
Christian

Hi Folks!

I can confirm that using the tape drive from another host does work like
a charm after manually creating the pscsi backend using configfs, yeah!
Thanks Christian for your input solving this issue! If you already have
a patch for targetcli to use sysfs' /bus/scsi/devices/... for detecting
the real device paths, I am eager to test it.

Sincerely,
Herbert.

Hi,

Fantastic!

I don't have one yet because I wanted to wait for your feedback (and
was quite busy with other things this week), but I'll work on one
during the weekend. I'll post an update to this bug report once I've
got a fixed package, and if you say it works for you I'll take care
of getting that into Debian.

Regards,
Christian

Hello Christian,

we are currently facing the same problem as described by Herbert at our
institute. Manual configuration as described by you works. Of course,
this hack will not survive a reboot. As a workaround, we wrote a custom
start script which initializes the export. It works, but is still some
kind of an awkward hack. Thus, a Debian compliant implementation would
be a nice Christmas present for us tape library users ... :-)

Thanks in advance and kind regards,
H. Elmann.

Hello Maintainers,

was this problem fixed ever?
I'm running exactly into the same problem while trying to configure
a changer and some tape drives as targets!
I don't like the manual hack in a production environment.
The problem was reported 4 years ago!
Any news on that?

Thanks and kind regards, Christian

I don't think so. I've CCed the other maintainer.