using a DDS2 tape in a DDS3 drive

[Marc Ahrendt]

i have a DDS3 tape drive (C1537A) on a L3000 running 11.11. we are writing Informix log archives to DDS2 tapes (Fuji DG-120M) via the "ontape" executable. my concerns are follows

1) compression: will Informix data be fairly compressed already before even getting hardware compressed at the tape drive? ...any feedback from Informix people would be nice, also if compressing compressed stuff could backfire making the end result larger on the tape than what was sent to the tape

2) device file: we are using /dev/rmt/0m with minor number of 0x042000 which correlates/links to /dev/rmt/c4t2d0BEST ...but i am not sure if its better to use 0x042001 which correlates to c4t2d0DDS (i have no idea what the "1" means in this minor number)

3) making a device file specific for the DDS3 drive and DDS2 tapes: would using "mksf -C tape -H 0/3/0/0.2.0 -b DDS2 -c 1 /dev/rmt/0m_DDS2_mode" be a good idea? ...i just do not know what to use for the "-c" option, but found the value one referenced in an ITRC post

4) data on the tape: can i confirm with "dd" the amount of data actually written to the tape? i thought that was possible

5) tape specs: are all DDS2 tapes 4GB/8GB? just wondering if 120M tapes are 4/8 and not 2/4

basically we had a backup failure and the DBA is assuming the tape was full or bad ...and at this point i only saw the following in "dmesg" (nothing from EMS)

SCSI: Request Timeout; Abort -- lbolt: 645187314, dev: cd042000, io_id: 40391ec
SCSI TAPE: dev = 0xcd042000 I/O error during close

thx, marc

[Bill Hassell · Accepted solution]

First, a DDS2 tape can be read in a DDS3 tape drive. The hardware detects whether compression was used to create the tape and decodes the data automatically.

1. Yes, compressing twice can make the data stream SLIGHTLY larger then without compression. If ontape is performing software compression before writing the data on tape, it is best to use the native recording mode (no compression).

2 and 3. Unfortunately, the insf and mksf commands make the device file names far too complicated (and numerous). There is no need to create additional device files for compression, just create a no compression device file. This should work by omitting thye -c option in mksf. Verify with the lssf command to decode the minor number.

4. There is no simple way to do this. dd only reads fixed record lengths and to make sense from the output, you need to know the backup program's format. If the record lengths change, dd is not going to be useful. It will also count just one file at a time. If there are multiple files on the tape (the backup program defines what a file is), you'll have to sit around for a couple of hours testing for additional files and the add up all the numbers.

Rather than waste a lot of time guessing, just download the tapeinfo program from:

ftp://hprc.external.hp.com/sysadmin/programs/tapeinfo/

which will report on the actual data recorded as well as the compression ratio (if any). NOTE: tapeinfo accidently matches a program in the online diagnostics, so I would copy this program into /usr/contrib/bin and rename it to something like tapestat or similar.

5. You can simply IGNORE the "compressed" capacity for any tape drive. There is only one capacity and that is native. The industry standard (only supported by strong marketing material) is to double the native capacity in hopes that the data you will backup is approximately 2:1 compressible, something that is impossible to predict.

For DDS tapes, every tape format is unique so the length of the tape is of academic interest only. A longer tape is 100% incompatible in an earlier drive. The older formats (DDS1, DDS2, DDS3, etc are forward compatible (with some caveats) but never backward compatible. The drives will eject incompatible tapes.

This link will provide EXCELLENT information about tapes and drives:

http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&cc=us&objectID=c00028345

A backup failure is a failure - the tape is of questionable value. Yes, it could be a bad tape. But unless the backup program is totally braindead, when the end of the tape is reached, the program will report an appropriate message and either request another tape, or quit because the program is incapable of handling multiple tapes. The error in syslog appears to be from a bad tape or a dirty drive. Use the cleaning tape followed by a new tape and run the backup again.

NOTE: Modern tape drives *WILL* wear out and must be replaced. This happens when the cleaning light comes on every few backups and using a cleaning tape does not help. Unlike audio cassette tapes, the read/write mechanisms extremely tight (and very small) tolerances and cannot be adjusted.

[Marc Ahrendt]

bill, thx for the detailed feedback

1) did as you recommended ...turned off compression at the drives

2&3) did as you recommended ...ignored all the existing device files and just made my own custom one that disables any hardware compression of data to the drive

4) did as you recommended ...confirmed compression using "tapeinfo"

5) in the end the tape was full ...seems that "ontape" got in a bad state and thus did not notify properly

thx for all the extra info, marc

[Marc Ahrendt]

bill, thx for the detailed feedback

1) did as you recommended ...turned off compression at the drives

2&3) did as you recommended ...ignored all the existing device files and just made my own custom one that disables any hardware compression of data to the drive

4) did as you recommended ...confirmed compression using "tapeinfo"

5) in the end the tape was full ...seems that "ontape" got in a bad state and thus did not notify properly

thx for all the extra info, marc