SDLT technology question

SDLT technology question

Post by Rob Tur » Sat, 20 Dec 2003 23:57:03


Hello group,

On older DLT drives there's a know issue with slow restores when the system
area of the tape hasn't properly been updated. This could happen because of
power loss or SCSI bus reset with the tape still in the drive. The next time
such a tape was loaded, the drive couldn't use the references from the
system area and had to read all the way through all data to find filemarks
or end-of-data again. This could cause delays of up to two hours.

I'm investigating a problem with someone using SDLT-320 drives who every now
and then experiences a similar delay. The tape gets loaded in the drive, and
then an unexplained delay of up to two hours occurs, after which the restore
completes normally. The drive is installed in a library, so we can't tell if
it's doing anything, and the problem occurs highly sporadic. This gave me
deja-vu of the issue with standard DLT. Does anyone know if SuperDLT is
still susceptible of this issue, or if any firmware fixes relating to the
system area exist for SDLT-320? They currently have 2E2E firmware in their
drives.

Thanks,
Rob
 
 
 

SDLT technology question

Post by aseltze » Wed, 07 Jan 2004 05:53:48

In article <3fe311c0$0$231$ XXXX@XXXXX.COM >, XXXX@XXXXX.COM
says...


The SDLT320 is susceptible to this type of behavior also. So if you
power cycle a drive with the tape installed it will not be able to
update the directory area (customer referred to this as the System
area). I would also suggest that you update his firmware to the
latest firmware qualified by the library vendor that the drive is
installed in. You are running V46 and V70 has been out for about 6
months. V80 will be released in January 2004.



_____ . .
' \\ . . |>>
O// . . |
\_\ . . |
| | . . . |
/ | . www.EvenEnterprises.com . . . |
/ .| XXXX@XXXXX.COM . . . |
/ . | 310-544-9439 / 310-544-9309 fax . . . o
----------------------------------------------------------------------
Authorized - DIRECT VAR/VAD/Distributor for new SCSI/FC-AL peripherals
NAS/SAN/RAID from HP, IBM, Seagate, EMC, QLogic, ATL, OverLand Data

 
 
 

SDLT technology question

Post by Rob Tur » Wed, 07 Jan 2004 06:43:16


XXXX@XXXXX.COM
system
of
time
filemarks
now
and
restore
if
their

Thanks for the confirmation, Andy. This behaviour explains exactly what the
customer sees.

The customer has scheduled a maintenance slot to get his drives upgraded. Do
you know where to get change/fix lists for SDLT firmware?

Thanks again,
Rob
 
 
 

SDLT technology question

Post by rene.koehn » Fri, 09 Jan 2004 17:30:35

gt; The customer has scheduled a maintenance slot to get his drives upgraded.
Do
Hello Rob,

the best place where I get this information is
http://www.support.storagetek.com .
Unfortunately you need a login for that site. If you are a customer or
partner you
can request a CRC password.

For your quick information, I've appended the release notes for V70.

Regards,

Rene

StorageTek Release Notes for Quantum SuperDLT320

Controller Firmware Revision V70 - Drive Firmware Revision V70

09/15/2003

Note: This release notes included all changes from V56 - V70



I. Software Release Identification



Drive Revision: 70 (46h).

Note: Inquiry data bytes 32d and 33d report "34" ASCII and "36" ASCII, which
convert to 4 and 6 hexadecimal respectively, and (46h) when converted to
decimal equals 70.



Controller Revision: 70 (46h).

Note: Inquiry data bytes 34d and 35d report "34" ASCII and "36" ASCII, which
convert to 4 and 6 hexadecimal respectively, and (46h) when converted to
decimal equals 70.



II. Controller firmware fixed, enhanced or changed


1.. Enhancement: Added parameter 0x8003 to Log Pages 02 (Write Errors) and
03 (Read Errors). The new parameter contains a raw count of Tracking Servo
errors.


2.. Enhancement: The cleaning LED will now extinguish if there is a
successful calibration on a tape. This makes the SDLT drive operation
consistent with the DLT 8000 drive.


3.. Fix the case when a long delay followed by the posting of the A503
event in the history log would generate a Bug Check 0xA21D which causes the
drive to reset itself.


4.. Enhancement: Support has been added for EMAM. This includes support
for the Read Attributes and Write Attributes SCSI commands. See EMAM
specification for further details.


5.. The EnaCheckDenOnWr EEROM option has been removed because all cases
that would have possibly allowed the drive to try and write an invalid
density have been resolved.


6.. Enhancement: Added an EEROM option called Mod4BlockSize with cause the
drive to check the Block Size field in the Block Descriptor of MODE SELECT
commands and verify it is a multiple of 4.


7.. Fix the problem: After a hard write error (HWE), a subsequent Rewind
command causes a BugCheck C926.


8.. Fix the problem: After completing message traffic introduced by
setting attention during a reconnection sequence on a READ or WRITE command,
the drive would send status instead of transferring more data, even if more
data was required.


9.. Fix the case when six Mode Selects are sent to the drive without delay
between commands during a cleaning cycle, the SCSI bus goes bus free and a
B80D is logged.


10.. Fix the case where a read command can take up to 18 minutes to
declare an error if the previous write of the cartridge failed with an
invalid file alignment field 1(FAF1) or course alignment field (CAF).


11.. Fix the problem: When writing small blocks of data (less than 32
bytes) and toggling compression on and off between blocks may cause
incorrect data to be returned on a subsequent read command.


12.. Fix the case where an odd byte, tape read on a wide SCSI bus would
transfer all but the last byte of data and hang. This could occur only if
the last 4 bytes of the data were in the next data block on the tape and in
a different envelope.


13.. Adjust the initial values in the table to match the drive
specific