SLR140 with new mt(1) [Was: Re: sa(4) driver changes available for test]

2015-03-11 Thread Harald Schmalzbauer
 Bezüglich Kenneth D. Merry's Nachricht vom 28.02.2015 01:08 (localtime):
…
>> Still just works fine ! :-) (stable_10.20150218.1-patchset with LTO2,
>> LTO3 and DDS5)
>> With DDS5, densitiy is reported as "unknown". If I remember correctly,
>> you have your DDS4 reporting "DDS4"?
> That means that we need to add DDS5 to the density table in libmt.  Can
> you send the output of 'mt status -v'?  It would actually be helpful for
> all three drives.

Hello,

I'd like to present some test results.
All tests were done with 10-stable-r273923 and Ken's
sa_driver_changes-patchset, reduced by the commited scsi-sys-code.

Unfortunately, there's a problem with appending files to any SLRtape. I
can write the first file, but trying to open a second file for writing,
results in "end of device" message. This problem doesn't exist for other
drives (tested on VXA-2 (also SCSI-2) and DAT72 (SCSI-3)) with exactly
same environment (all currently connected SCSI drives (7) are on one
mpt(4) bus).
After the first "end of device" message, consecutive write attempts lead
to "Operation not permitted".

According to the datasheet
(http://www.tandbergdata.ru/products/files/SLR140_DS_605_ENG.pdf), the
drive should speak SCSI-3, but camcontrol shows SCSI-2.

##
TandbergData SLR140 Drive
##
camcontrol inq $TAPE -v
pass3:  Removable Sequential Access SCSI-2 device
pass3: Serial Number SN140253489
pass3: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Command
Queueing Enabled

Density 0x36 = ALRF-6, 186000 bpi, SLR140 drive + SLR140tape:
SLRtape140 (8mm DualReel, 70GB native, 505.9m length, 5.5MiB/s)
mt status -v
Drive: sa3:  Serial Number: SN140253489
-
Mode Density Blocksize bpi Compression
Current: 0x36:UNKNOWN variable 0 enabled (0x3)
-
Current Driver State: at rest.
-
Partition: 0 Calc File Number: 0 Calc Record Number: 0
Residual: 0 Reported File Number: -1 Reported Record Number: -1
Flags: None
-
Tape I/O parameters:
Maximum I/O size allowed by driver and controller (maxio): 131072 bytes
Maximum I/O size reported by controller (cpi_maxio): 131072 bytes
Maximum block size supported by tape drive and media (max_blk): 262144 bytes
Minimum block size supported by tape drive and media (min_blk): 1 bytes
Block granularity supported by tape drive and media (blk_gran): 0 bytes
Maximum possible I/O size (max_effective_iosize): 131072 bytes

Minimum blocksize to reach highest throughput, thus sustained write of
uncompressable data (from /dev/random): 24k@5.5MiB/s

mt status
-
Current Driver State: at rest.
-
Partition: 0 Calc File Number: 1 Calc Record Number: 0
Residual: 0 Reported File Number: -1 Reported Record Number: -1
Flags: None

"short READ POSITION"
camcontrol cmd $TAPE -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - | hd
 30 00 00 00 00 00 06 83 00 00 00 00 00 00 00 00 |0...|
0010 00 00 00 00 ||
0014
"vendor READ POSITION"
camcontrol cmd $TAPE -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - | hd
camcontrol: error sending command
(pass3:mpt1:0:13:0): READ POSITION. CDB: 34 01 00 00 00 00 00 00 00 00
(pass3:mpt1:0:13:0): CAM status: SCSI Status Error
(pass3:mpt1:0:13:0): SCSI status: Check Condition
(pass3:mpt1:0:13:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field
in CDB)
(pass3:mpt1:0:13:0): Command byte 1 bit 0 is invalid
"long READ POSITION"
camcontrol cmd $TAPE -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd
camcontrol: error sending command
(pass3:mpt1:0:13:0): READ POSITION. CDB: 34 06 00 00 00 00 00 00 00 00
(pass3:mpt1:0:13:0): CAM status: SCSI Status Error
(pass3:mpt1:0:13:0): SCSI status: Check Condition
(pass3:mpt1:0:13:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field
in CDB)
(pass3:mpt1:0:13:0): Command byte 1 bit 2 is invalid

Different tapes
--
Density 0x34 = ALRF-1, 15400 bpi:
SLRtape100 (8mm DualReel, 50GB native, 457.2m length, 4.7MiB/s)
SLRtape40 (8mm DualReel, 20GB native, 187,5m length, 4.7MiB/s)
Mode Density Blocksize bpi Compression
Current: 0x36:UNKNOWN variable 0 enabled (0x3)

Density 0x30 = MLR3, 103124 bpi:
SLRtape50 (¼" (Quarter inch) DualReel, 25GB native, 457.2m length, 1.8MiB/s)

##
Exabyte VXA-2
##
camcontrol inq $TAPE -v
pass9:  Removable Sequential Access SCSI-2 device
pass9: Serial Number 0085105377
pass9: 80.000MB/s transfers (40.000MHz, offset 32, 16bit), Command
Queueing Enabled

Density 0x81 = ??? (no info about areal density found, nor bpi/ftpi)
VXA-2 Drive + V10 Tape
VXA V10 (8mm DualReel, 20GB native, 120m length, 5.6MiB/s)
mt status -v
Drive: sa4:  Serial Number: 0085105377
-
Mode Density Blocksize bpi Compression
Current: 0x81:UNKNOWN variable 0 enabled (0x3)
-
Current Driver State: at rest.
-
Partition: 0 Calc File Numb

Re: SLR140 with new mt(1) [Was: Re: sa(4) driver changes available for test]

2015-03-11 Thread Kenneth D. Merry
On Wed, Mar 11, 2015 at 20:26:49 +0100, Harald Schmalzbauer wrote:
>  Bez?glich Kenneth D. Merry's Nachricht vom 28.02.2015 01:08 (localtime):
> ?
> >> Still just works fine ! :-) (stable_10.20150218.1-patchset with LTO2,
> >> LTO3 and DDS5)
> >> With DDS5, densitiy is reported as "unknown". If I remember correctly,
> >> you have your DDS4 reporting "DDS4"?
> > That means that we need to add DDS5 to the density table in libmt.  Can
> > you send the output of 'mt status -v'?  It would actually be helpful for
> > all three drives.
> 
> Hello,
> 
> I'd like to present some test results.
> All tests were done with 10-stable-r273923 and Ken's
> sa_driver_changes-patchset, reduced by the commited scsi-sys-code.

Thank you for testing all of these drives and media!  I really appreciate
it!

> Unfortunately, there's a problem with appending files to any SLRtape. I
> can write the first file, but trying to open a second file for writing,
> results in "end of device" message. This problem doesn't exist for other
> drives (tested on VXA-2 (also SCSI-2) and DAT72 (SCSI-3)) with exactly
> same environment (all currently connected SCSI drives (7) are on one
> mpt(4) bus).
> After the first "end of device" message, consecutive write attempts lead
> to "Operation not permitted".
> 
> According to the datasheet
> (http://www.tandbergdata.ru/products/files/SLR140_DS_605_ENG.pdf), the
> drive should speak SCSI-3, but camcontrol shows SCSI-2.
> 
> ##
> TandbergData SLR140 Drive
> ##
> camcontrol inq $TAPE -v
> pass3:  Removable Sequential Access SCSI-2 device
> pass3: Serial Number SN140253489
> pass3: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Command
> Queueing Enabled

This sounds like it could be an End Of Tape (EOT) model issue.  There is a
quirk entry in the driver for other SLR drives, but it probably won't match
this particular drive because of a leading space in the INQUIRY data:

{
{ T_SEQUENTIAL, SIP_MEDIA_REMOVABLE, "TANDBERG",
  " SLR*", "*"}, SA_QUIRK_1FM, 0
},

So, try doing a 'mt geteotmodel' on that drive.  It is probably set to 2
filemarks.  If it is, do:

mt seteotmodel 1

Obviously, if it is set to 1, try 2 and see what happens.

If that is the case, we can adjust the quirk to match that drive.

> Density 0x36 = ALRF-6, 186000 bpi, SLR140 drive + SLR140tape:
> SLRtape140 (8mm DualReel, 70GB native, 505.9m length, 5.5MiB/s)

Do you have any source documentation for the BPI data?  Any information
on the number of tracks or the other fields that might go in the mt(1) man
page?  (We can obviously put it in with that, it's just nice to put it all
in if we have it.)

> mt status -v
> Drive: sa3:  Serial Number: SN140253489
> -
> Mode Density Blocksize bpi Compression
> Current: 0x36:UNKNOWN variable 0 enabled (0x3)
> -
> Current Driver State: at rest.
> -
> Partition: 0 Calc File Number: 0 Calc Record Number: 0
> Residual: 0 Reported File Number: -1 Reported Record Number: -1
> Flags: None
> -
> Tape I/O parameters:
> Maximum I/O size allowed by driver and controller (maxio): 131072 bytes
> Maximum I/O size reported by controller (cpi_maxio): 131072 bytes
> Maximum block size supported by tape drive and media (max_blk): 262144 bytes
> Minimum block size supported by tape drive and media (min_blk): 1 bytes
> Block granularity supported by tape drive and media (blk_gran): 0 bytes
> Maximum possible I/O size (max_effective_iosize): 131072 bytes
> 
> Minimum blocksize to reach highest throughput, thus sustained write of
> uncompressable data (from /dev/random): 24k@5.5MiB/s

That's pretty good!

> mt status
> -
> Current Driver State: at rest.
> -
> Partition: 0 Calc File Number: 1 Calc Record Number: 0
> Residual: 0 Reported File Number: -1 Reported Record Number: -1
> Flags: None
> 
> "short READ POSITION"
> camcontrol cmd $TAPE -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - | hd
>  30 00 00 00 00 00 06 83 00 00 00 00 00 00 00 00 |0...|
> 0010 00 00 00 00 ||
> 0014
> "vendor READ POSITION"
> camcontrol cmd $TAPE -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - | hd
> camcontrol: error sending command
> (pass3:mpt1:0:13:0): READ POSITION. CDB: 34 01 00 00 00 00 00 00 00 00
> (pass3:mpt1:0:13:0): CAM status: SCSI Status Error
> (pass3:mpt1:0:13:0): SCSI status: Check Condition
> (pass3:mpt1:0:13:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field
> in CDB)
> (pass3:mpt1:0:13:0): Command byte 1 bit 0 is invalid
> "long READ POSITION"
> camcontrol cmd $TAPE -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd
> camcontrol: error sending command
> (pass3:mpt1:0:13:0): READ POSITION. CDB: 34 06 00 00 00 00 00 00 00 00
> (pass3:mpt1:0:13:0): CAM status: SCSI Status Error
> (pass3:mpt1:0:13:0): SCSI status: Check Condition
> (pass3:mpt1:0:13:0)