- Community Home
- >
- Servers and Operating Systems
- >
- Legacy
- >
- Operating System - Tru64 Unix
- >
- SDLT tape saga...please help
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-15-2005 09:32 PM
11-15-2005 09:32 PM
SDLT tape saga...please help
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 ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-15-2005 11:22 PM
11-15-2005 11:22 PM
Re: SDLT tape saga...please help
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-16-2005 12:36 AM
11-16-2005 12:36 AM
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_
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-16-2005 01:21 AM
11-16-2005 01:21 AM
Re: SDLT tape saga...please help
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-16-2005 02:09 AM
11-16-2005 02:09 AM
Re: SDLT tape saga...please help
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.