[stgt] VTL tape not working
Albert Pauw
albert.pauw at gmail.com
Sat Feb 21 13:15:05 CET 2009
Ok,
here's my test. It seems that the tape-file is not updated at all.
here is what I have/did:
the relevant part of /etc/tgt/targets.conf:
<target iqn.2008-09.com.example:server.tape>
backing-store /root/tapes/tape.bin
# incominguser someuser secretpass12
# outgoinguser userA secretpassA
write-cache off
vendor_id QUANTUM
product_id HD100
product_rev 0010
scsi_id QUANTUM
scsi_sn 01234A
device-type tape
removable 1
sense_format 0
online 1
lun 1
MaxRecvDataSegmentLength 8192
MaxXmitDataSegmentLength 8192
HeaderDigest CRC32C
DataDigest None
InitialR2T Yes
MaxOutstandingR2T 1
ImmediateData Yes
FirstBurstLength 65536
MaxBurstLength 262144
DataPDUInOrder Yes
DataSequenceInOrder Yes
ErrorRecoveryLevel 0
IFMarker No
OFMarker No
DefaultTime2Wait 2
DefaultTime2Retain 20
OFMarkInt Reject
IFMarkInt Reject
MaxConnections 1
</target>
Started tgtd, logged in with open-iscsi and checked it:
[root at orange var]# tgt-admin -s
Target 1: iqn.2008-09.com.example:server.tape
System information:
Driver: iscsi
State: ready
I_T nexus information:
I_T nexus: 1
Initiator: iqn.1994-05.com.fedora:56a2fe6ddc
Connection: 0
IP Address: 127.0.0.1
LUN information:
LUN: 0
Type: controller
SCSI ID: deadbeaf1:0
SCSI SN: beaf10
Size: 0 MB
Online: Yes
Removable media: No
Backing store: No backing store
LUN: 1
Type: tape
SCSI ID: QUANTUM
SCSI SN: 01234A
Size: 0 MB
Online: Yes
Removable media: Yes
Backing store: /root/tapes/tape.bin
Account information:
ACL information:
ALL
Seems ok, check the scsi stuff:
[root at orange tapes]# lsscsi
[0:0:0:0] disk ATA TOSHIBA MK6026GA PA20 /dev/sda
[1:0:0:0] cd/dvd MATSHITA DVD-RAM UJ-841S 1.20 /dev/sr0
[2:0:0:0] storage IET Controller 0001 -
[2:0:0:1] tape QUANTUM HD100 0010 /dev/st0
Ok as well.
[root at orange tapes]# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (41010000):
BOT ONLINE IM_REP_EN
Ok, BOT=Beginning Of Tape, so that is fine. Let's write some random data
to the
non-rewinding device:
[root at orange tapes]# dd if=/dev/urandom of=/dev/nst0 bs=1024 count=1024
1024+0 records in
1024+0 records out
1048576 bytes (1.0 MB) copied, 0.847174 s, 1.2 MB/s
And check the file size:
[root at orange tapes]# ls -la
total 12
drwxr-xr-x 2 root root 4096 2009-02-21 12:58 .
drwxr-x--- 35 root root 4096 2009-02-21 12:56 ..
-rw-r----- 1 root root 1200 2009-02-21 13:01 tape.bin
Odd, file has not been updated!
[root at orange tapes]# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=1, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (81010000):
EOF ONLINE IM_REP_EN
Yup, were at the End Of Tape.
[root at orange tapes]# mt -f /dev/st0 status
SCSI 2 tape drive:
File number=0, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (41010000):
BOT ONLINE IM_REP_EN
Yup, reading rewinding device sets it back to the beginning, this is
correct.
Try a bigger set of random data.
[root at orange tapes]# dd if=/dev/urandom of=/dev/nst0 bs=1024 count=10240
10240+0 records in
10240+0 records out
10485760 bytes (10 MB) copied, 8.33931 s, 1.3 MB/s
Still no update of the file!
[root at orange tapes]# ll
total 4
-rw-r----- 1 root root 1200 2009-02-21 13:01 tape.bin
Let it sync, just in case.
[root at orange tapes]# sync
Check the tape device status
[root at orange tapes]# mt -f /dev/nst0 status
SCSI 2 tape drive:
File number=1, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x0 (default).
Soft error count since last status=0
General status bits on (81010000):
EOF ONLINE IM_REP_EN
This is ok. Rewind it now.
[root at orange tapes]# mt -f /dev/nst0 rewind
Just check the tape itself again with tgtimg,
[root at orange tapes]# tgtimg --op show --file=tape.bin crc error
Unknown media format version b8712175
Oh dear, something's wrong here. It was fine just after creation.
FUJITA Tomonori wrote:
> On Mon, 16 Feb 2009 19:06:06 +0100
> Albert Pauw <albert.pauw at gmail.com> wrote:
>
>
>> FUJITA Tomonori wrote:
>>
>>> Can you try again with tgtimg instead of mktape?
>>>
>>>
>> Tried that as well. Got a segfault again, see /var/log/messages:
>>
>> scsi2 : iSCSI Initiator over TCP/IP
>> scsi 2:0:0:0: RAID IET Controller 0001 PQ: 0 ANSI: 5
>> scsi 2:0:0:0: Attached scsi generic sg2 type 12
>> scsi 2:0:0:1: Sequential-Access IET VIRTUAL-TAPE 0001 PQ: 0 ANSI: 5
>> scsi 2:0:0:1: Attached scsi generic sg3 type 1
>> st: Version 20080504, fixed bufsize 32768, s/g segs 256
>> Driver 'st' needs updating - please use bus_type methods
>> st 2:0:0:1: Attached scsi tape st0
>> st 2:0:0:1: st0: try direct i/o: yes (alignment 1 B)
>> osst :I: Tape driver with OnStream support version 0.99.4
>> osst :I: $Id: osst.c,v 1.73 2005/01/01 21:13:34 wriede Exp $
>> Driver 'osst' needs updating - please use bus_type methods
>> st0: Block limits 4 - 1048576 bytes.
>> tgtd[12438]: segfault at 4 ip 08054468 sp acb5a320 error 4 in
>> tgtd[8047000+25000]
>> connection1:0: detected conn error (1011)
>> st0: Error 20000 (sugg. bt 0x0, driver bt 0x0, host bt 0x2).
>>
>> and the file systems of the tape file is 10kbytes, as before
>>
>
> Can you tell me the exact procedure to reproduce this?
>
> Thanks,
>
--
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