Neil,
As long as we're discussing the 3583, I'll share my experiences.
TSM 4.1.5 on AIX 4.3.3; 3583-L72 w/ 4 drives; HVDS.
Collocated data for 14 nodes.
After about a month of operation, the picker and picker controller failed.
Left two tapes stuck in drives. IBM HW Support replaced the picker and
controller, then upped the firmware - it WAS a month old - and library
worked AOK for about 3 months.
Last week we again had the "tape stuck in drive" problem. IBM HW Support
replaced the drive, but when we loaded the formerly stuck tape in the
drive, it jammed so bad that we couldn't remove it even if we disassembled
the drive. IBM put the old drive back in and took the no-longer-new drive
with stuck tape with them.
Whoever thought up the idea for the "copypool" deserves a raise. I
restored 1/3 million files totalling 70 GB from DLT in 7 hours.
Two days later another tape stuck in old drive which stuck the "gone" tape.
IBM HW Support replaced the drive and this time I pulled the tape rather
than risk another jam.
Restored 40K files / 100 GB from DLT in 10 hours simulaneous to weekly TSM
maintenance (expiration, etc.).
When we put in the new drive, its firware differed from the other three so
we got lots of library errors.
We had already updated the library firmware so we tried just updating the
drive firmware via AIX. Note that library firmware is updated via RS-232
while drive firmware is updated via SCSI from server.
Eventually updated the library firmware again only to find that the
firmware for the "drive sled" is included in the library firmware, but not
the drive firmware.
System has been working AOK for about a week now.
We have all four drives on one HV Diff SCSI adapter. IBM always gets that
pained look when we tell them that. We see consistent througput of 16
MB/s. I know we're supposed to spread the load but my F50 has all its
slots in use. Maybe this year a bigger server.
We run four parallel processes to the DLT library when backing up to the
copypool. Both the 3583 and the HP 4/40 top out at about 16 MB/s
regardless of source or direction of data transfer.
Oh, and we average 165 GB per tape.
While at Dell's facility, they showed an LTO library that looked exactly
like a 3583, only it had "Dell" in place of the IBM nametag.
Just sharing...
Tab Trepagnier
TSM Administrator
Laitram Corporation
Neil Sharp <[EMAIL PROTECTED]>@VM.MARIST.EDU> on 02/07/2002 05:03:29 AM
Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Re: IBM 3583 Library question.
Just a word of warning. We had a very unsuccessful install of a 3583 with
TSM on a AIX box. The library turned out to be very unreliable to the point
where every component was replaced but still it did not function correctly.
In the end IBM held their hands up and admitted that there where issues
with this model. We are now running on a 3584 which is much better.
Good luck.
Neil Sharp
Dyadic Systems Limited
Tel : 01256-811125
E-mail : [EMAIL PROTECTED]
"Seay, Paul"
<seay_pd@NAPTHEO To:
[EMAIL PROTECTED]
N.COM> cc:
Sent by: "ADSM: Subject: Re: IBM 3583
Library question.
Dist Stor
Manager"
<[EMAIL PROTECTED]
T.EDU>
07/02/2002 06:11
Please respond
to "ADSM: Dist
Stor Manager"
Generally, you want to use *stcbn if it is available. The reason is the
drive will stay at the point between closes and reports the location block
on open. Remember these are smart drives like Magstar and can skip to a
block as requested. Typically, a backup product does that. However, I
will
defer to rest if they have a better answer.
-----Original Message-----
From: bbullock [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 06, 2002 4:16 PM
To: [EMAIL PROTECTED]
Subject: IBM 3583 Library question.
We are hooking a new IBM 3583 tape library up to a Solaris
host to be a remote site TSM server. The Ultrium drives have various
/dev/?st... devices through which we can access them. The no-brainer was
to
use the driver that tells the drive to compress the data, but I'm not sure
between these 2 options:
/dev/rmt/*stc <- compression and "Rewind on Close"
/dev/rmt/*stcn <- compression but "No Rewind on Close"
I can't find anything in the TSM or library documents on which to
use. Does TSM get confused if a tape were to be mounted and it was not at
the beginning? Kind of seems like we would reduce tape and drive wear by
using the "no rewind" device drives, and writes might happen quicker it the
tape is not rewound...
Any suggestions would be helpful. (the listserv archive
site
is currently inaccessible.)
Thanks,
Ben
Micron Technology Inc.
