SCSI DDS LOG DATA: (longish)
Common DDS questions:
How many times has the tape been used?
Am I getting any errors?
What kind of compression ratio am I getting?
How much room is left on the end of the tape?
Well, after playing with the SCSIDDS diagnostic in SYSDIAG, I can answer
some of these questions but as usual other questions arise.
Note: On 4.5 and 5.0 this diagnostic requires a password from the response
center. Why they require a password for a tape diagnostic is beyond me!
Very soon they will have to do something because this is the same
diagnostic you use to get the firmware revision, and most updates require
checking this.
What I would really like to see is a standard user utility that will
provide at least this minimal data. Better yet would be a tape management
system that tracks tapes and their usage history!
The following is a list of the types of log data kept in the C1533A DDS
drive. Other HP DDS drives have a subset of this list.
0 - Write Error Log, Read Error Log, Tape Log
1 - Write Error Counters Log
2 - Read Error Counters Log
3 - Tape Log
4 - Channel Trace Log
5 - Buffer Trace Log
6 - Device Trace Log
7 - Write Frames Error Counters Log
8 - Read Frames Error Counters Log
9 - Bad Group Log
10 - Drive Counters Log
11 - Mechanism Counters Log
12 - Tape Capacity Log
13 - Data Compression Transfer Log
14 - Data Compression Trace Log
15 - EXIT Logs
This is a sample job that I set up to dump and then clear the logs. It
turns out that some of the logs are cumulative, and must me reset to get a
good reading. I had much trouble attempting to clear the logs prior to a
backup, then running the backup and reading the logs.
!JOB DDSLOGS,MANAGER.SYS;OUTCLASS=LP,1,1
!SYSDIAG
RUN SCSIDDS;LDEV=9;SECTION=50
LOGS
3
1
Y
13
1
Y
12
1
N
CLEARLOG
0
EXIT
EXIT
!EOJ
The output from the job contains the following tables. The tape log,
compression log, and the capacity log.
The tape log shows the tape load count, read & write counts, and most
importantly the retry counts.
The compression log shows the kbytes into and out of the compression
routines. In the tests I performed I noticed that STORE must perform some
minimal compression because the kbytes in is about 96% of the total bytes
for the files stored. The kbytes to tape can be devoid by the kbytes in the
tape capacity log to get a percentage of the tape used.
===================================================================
TAPE LOG (dec)
===================================================================
Total tape load = 22
Current groups written = 0
Current RAW retries = 0
Current groups read = 0
Current ECC-3 retries = 0
Previous groups written = 2959
Previous RAW retries = 0
Previous groups read = 2
Previous ECC-3 retries = 0
Total groups written = 2959
Total RAW retries = 0
Total groups read = 2
Total ECC-3 retries = 0
===================================================================
DATA COMPRESSION TRANSFER LOG (dec)
===================================================================
Entities Written = 9057
Entities Read = 3
Records Written = 140918
Records Read = 1
Kbytes to DC = 1654723
Kbytes from DC = 0
Kbytes to Tape = 365607
Kbytes from Tape = 0
Logical Entity Size = 188
Physical Entity Size = 126
Non-DCLZ Entities = 0
===================================================================
TAPE CAPACITY LOG (dec)
===================================================================
Remaining capacity, partition 0 (in kb) = 3316087
Remaining capacity, partition 1 (in kb) = 0
Maximum capacity, partition 0 (in kb) = 3316087
Maximum capacity, partition 1 (in kb) = 0
New Questions/Issues:
How do groups, entities, and records relate to kbytes and each other?
Why is the maximum capacity of 3.3GB related as 4GB?
How many tape loads before retirement?
How many retries before retirement?
What can happen to decrease the tape capacity, and can a DDS tape be
partitioned?
|
