Operating System - Tru64 Unix
1830250 Members
2649 Online
110000 Solutions
New Discussion

SDLT tape saga...please help

 
Phil Pollard
Occasional Contributor

SDLT tape saga...please help

I am having real problems with a Quantum SDLT320 tape drive on a DS20E.
Tru64 v51a patched to patch kit 6.
I have run tapex against the drive and it produces errors. I have tried the drive on a Sun machine and it is O.K. I have tried new tapes (in fact all the tapes are new tapes). I've tried cleaning the drive, still I get errors.
For the backups I use dump as all the filesystems are UFS. It has a tendency to bomb out when it hits a large file as some of the DB files are > 12 Gb in size.
I am really struggling now. Anyone any ideas ?
4 REPLIES 4
Alexey Borchev
Regular Advisor

Re: SDLT tape saga...please help

I would suggest:
1) To check up SCSI
- termination (try external terminator(s))
- Another adapter
- Limit speed to 20 or 40 MB\s
2) To try vdump.
Vdump can be used for backing up UFS too.
3)? Maybe, try to
dd if=/dev/disk/dsk1c of=/dev/tape/tape0_d1 bs=64k
- to see if any errors with dd.
The fire follows shedule...
Johan Brusche
Honored Contributor

Re: SDLT tape saga...please help


Phil,

With pk#6 the SDLT320 should be defined in the /etc/ddr.dbase file. Please check if it is really in there.

Rgds,
___ Johan./

_JB_
Phil Pollard
Occasional Contributor

Re: SDLT tape saga...please help

I've tried a few things :

dd gives I/O error
tar (gnu) gives I/O error
I've tried d0/d1/d2/d3/d4/d5/d6/d7 all give the same results
Extract from /etc/ddr.dbase

SCSIDEVICE
#
# Matches SDLT320
#
Type = tape
Name = "QUANTUM" "SDLT320"
#
#
PARAMETERS:
TypeSubClass = tk
TagQueueDepth = 0
MaxTransferSize = 0x0ffffffc # (16MB - 4)
ReadyTimeSeconds = 120 # seconds

DENSITY:
#
DensityNumber = 0
DensityCode = 0x48
CompressionCode = 0x1
Buffered = 0x1
...
There is more but I'll just put part here.
hwmgr -get attributes gives :
path_port_id_0 = 0
path_target_id_0 = 5
path_lun_id_0 = 0
path_dev_i/o_cnt_0 = 0
path_state_0 = 1
path_new_state_0 = 0
path_xfer_0 = 0
path_wds_0 = 0
path_avserv_0 = 0
path_pxfer_0 = 0
path_avwait_0 = 0
registration_time = Tue Nov 15 13:15:23 2005
user_name = (null) (settable)
location = (null) (settable)
software_module = (null)
state = available
state_previous = unknown
state_change_time = none
event_count = 4
last_event_time = Wed Nov 16 12:32:52 2005
access_state = online
access_state_change_time = none
capabilities = 0
indicted = 0
indicted_probability = (null)
indicted_urgency = (null)
disabled = 0
name = SCSI-WWID:02000008:500e-09e0-0013-82b7
category = tape
architecture = SCSI
phys_location = bus-0-targ-5-lun-0
dev_base_name = tape18
model = SDLT320
firmware_rev = 4B4B
read_ops = 59750
write_ops = 1208897
read_bytes = 247551010
write_bytes = 12461489755
current_density = 73
block_size = 0
records = 0
filemarks = 0
rewind_timo = 3600
space_timo = 3600
load_timo = 3600
space_eod_timo = 3600
resid = 0
sense_info = 0
sense_key = 11
soft_err = 0
hard_err = 53
active_paths = 1
standby_paths = 0
failed_paths = 0
donot_use_paths = 0
path_fail_limit = 1
subsys_dev_handle = 15
manufacturer = QUANTUM
consistent_name = 1
ccmn_specific_addr = 18446739677725342272
cluster_dev_directions = 0 (settable)
drvr_max_xfer = 268435452

Only things I can think of now are:
1. An obsure parameter I have missed.
2. some firmware (scsi card, DS20E...)
3. cable problem ?

Thanks
Phil P
Vladimir Fabecic
Honored Contributor

Re: SDLT tape saga...please help

Try to connect tape drive on another SCSI HBA.
On what HBA is it connected now?
What firmware you have (I do not think this is a firmware issue)?
Try to use other SCSI cable. Once I had very strange behavior of SDLT 110/220 and fixed it with new cable.
I/O error may be issue of hardware problem.
In vino veritas, in VMS cluster