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: <TANDBERG SLR140 0605> 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: <TANDBERG SLR140 0605> 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_at_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 > 00000000 30 00 00 00 00 00 06 83 00 00 00 00 00 00 00 00 |0...............| > 00000010 00 00 00 00 |....| > 00000014 > "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 Good to know that it doesn't support long position information. > 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) Hmm, that is a vast difference in bpi between 0x34 and 0x36. 186000 for 0x36 (close to LTO-2), and 15400 for 0x34 (close to QIC-320). Is one of thoes incorrect? > 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: <EXABYTE VXA-2 1009> 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) I'll look around and see if I can dig anything up on that. > mt status -v > Drive: sa4: <EXABYTE VXA-2 1009> Serial Number: 0085105377 > --------------------------------- > Mode Density Blocksize bpi Compression > Current: 0x81: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): 245760 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_at_5.6MiB/s > > mt status > --------------------------------- > Current Driver State: at rest. > --------------------------------- > Partition: 0 Calc File Number: 4 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 > 00000000 00 00 00 00 00 00 39 39 00 00 00 00 00 00 00 00 |......99........| > * > 00000010 > > "vendor READ POSITION" > camcontrol cmd $TAPE -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - | hd > 00000000 00 00 00 00 00 00 39 39 00 00 00 00 00 00 00 00 |......99........| > * > 00000010 > > "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 > (pass9:mpt1:0:15:0): READ POSITION. CDB: 34 06 00 00 00 00 00 00 00 00 > (pass9:mpt1:0:15:0): CAM status: SCSI Status Error > (pass9:mpt1:0:15:0): SCSI status: Check Condition > (pass9:mpt1:0:15:0): SCSI sense: ILLEGAL REQUEST asc:24,0 (Invalid field > in CDB) > (pass9:mpt1:0:15:0): Command byte 1 bit 2 is invalid So, no long position information there either. > No other tape cartridges available for testing at the moment (X6 to > follow together with VXA-320 drive results) > > ################ > Seagate/Quantum DAT72 (DDS-5) > ################ > camcontrol inq $TAPE -v > pass0: <SEAGATE DAT DAT72-052 A16K> Removable Sequential Access SCSI-3 > device > pass0: Serial Number HV082SN > pass0: 80.000MB/s transfers (40.000MHz, offset 32, 16bit), Command > Queueing Enabled > > Density 0x47 = PRML, 162000 bpi, DAT72 Drive + DAT72 media > DAT-72 Cartridge (3.81mm DualReel, 36GB native, 170m length, 3.2MiB/s): I have that one in FreeBSD/head, so it will go into stable/10 with the rest of the changes. > mt status -v > Drive: sa0: <SEAGATE DAT DAT72-052 A16K> Serial Number: HV082SN > --------------------------------- > Mode Density Blocksize bpi Compression > Current: 0x47:UNKNOWN variable 0 enabled (DCLZ) > --------------------------------- > Current Driver State: at rest. > --------------------------------- > Partition: 0 Calc File Number: 0 Calc Record Number: 0 > Residual: 0 Reported File Number: 0 Reported Record Number: 0 > Flags: BOP > --------------------------------- > 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): 16777215 > 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): <4k_at_3.2MiB/s > > mt status > --------------------------------- > Current Driver State: at rest. > --------------------------------- > Partition: 0 Calc File Number: 7 Calc Record Number: 0 > Residual: 0 Reported File Number: 7 Reported Record Number: 115634 > > "short READ POSITION" > camcontrol cmd $TAPE -v -c "34 0 0 0 0 0 0 0 0 0" -i 20 - | hd > 00000000 30 00 00 00 00 01 c3 b2 00 01 c3 b2 00 00 00 00 |0...............| > 00000010 00 00 00 00 |....| > 00000014 > "vendor READ POSITION" > camcontrol cmd $TAPE -v -c "34 1 0 0 0 0 0 0 0 0" -i 20 - | hd > 00000000 30 00 00 00 00 01 c3 ab 00 01 c3 ab 00 00 00 00 |0...............| > 00000010 00 00 00 00 |....| > 00000014 > > "long READ POSITION" > camcontrol cmd $TAPE -v -c "34 6 0 0 0 0 0 0 0 0" -i 32 - |hd > 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 01 c3 b2 |................| > 00000010 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 00 |................| > 00000020 Ahh, so it does support long read position data. :) > Different tapes > ---------------------- > Density 0x26 = PRML, 122000 bpi > DDS4 Cartridge (3.81mm DualReel, 20GB native, 150m length,): > Mode Density Blocksize bpi Compression > Current: 0x26:DDS-4 variable 97000 enabled (DCLZ) > > Density 0x25 = PRML, 122000 bpi > (3.81mm DualReel, 36GB native, 125m length, ) > Mode Density Blocksize bpi Compression > Current: 0x25:DDS-3 variable 97000 enabled (DCLZ) Great, thanks! > I could also provide LTO-3 (and LTO-2) results ? after I identified the > U320 killer in the bus? > Like reported earlier, LTO-2 worked like a charm. > DLT-V4 and VXA-320 will follow soon too ? I'm waiting for some media. Thanks for all of the testing! I appreciate it! Ken -- Kenneth Merry ken_at_FreeBSD.ORGReceived on Thu Mar 12 2015 - 02:18:41 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:56 UTC