Re: Very slow restores (days), hours to locate files
2005-07-07 11:13:14
TO identify the volumes with the corrupted CM, just do a checkin with
CHECKL=YES. This will then issue a tapealert message for a
tape that has a bad/corrupted CM. If it's a scratch tape, then the CM will be
written as you write to the tape. For tapes with data
on them, you can MOVE DATA to another drive and let it go scratch, or use the
tapeutil utility to mount the tape and forward to the
end of the tape. That causes the drive to re-write the CM index.
That is after you've identified the problem that is corrupting your CM chips.
It could be firmware, but at one client site of mine,
it was a faulty drive.
Bill Boyer
"Some days you're the bug, some days you're the windshield" - ??
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Rejean Larivee
Sent: Thursday, July 07, 2005 10:51 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Very slow restores (days), hours to locate files
Hello Robin,
the TSM server does not maintain the LTO memory cartridge and would therefore
not be the source of the corruption. A corrupted
memory cartridge comes from defective media, faulty/dirty hardware/drive or
firmware/microcode problem.
As others have already recommended, you should consider upgrading the firmware
of the LTO drives to take care of past problems with
LTO CM.
It appears the latest firmware for the LTO GenII drives at this time is 53Y2,
for fiber attached drives. You can verify the firmware
of your drives using "lscfg -vl rmt*".
For a list of what is fixed in 53Y2, see here :
http://www-1.ibm.com/support/docview.wss?rs=0&uid=ssg1S1002360
Have a great day !
Rejean Larivee
IBM Tivoli Storage Manager support
Robin Sharpe
<Robin_Sharpe@BER
LEX.COM> To
Sent by: "ADSM: ADSM-L AT VM.MARIST DOT EDU
Dist Stor cc
Manager"
<[email protected] Subject
.EDU> Re: Very slow restores (days),
hours to locate files
07/06/2005 04:12
PM
Please respond to
"ADSM: Dist Stor
Manager"
Sorry about the omission, Rich.
These restores were started via the Windows GUI. I believe they just selected
the C: drive and specified "Restore if newer" (an
option which I don't think is available via the command line!). I believe this
created a No-Query Restore, because it did create a
Restartable Restore.... AFAIK there is a one-to-one correspondence (right?)
In the meantime, I checked the Technote... Then, I checked my Activity Log for
the last 24 hours... and I found 33 LTO volumes that
presented the cartridge memory message! So, now I have the smoking gun, and I
suppose I could do "move data" against those volumes,
but I suspect there are many more, and I would like to know what's causing the
corruption and how to
prevent it! If I don't hear anything from the group, I'll open a call
with Tivoli.
Thanks very much for the information!
-Robin
Richard Sims
<rbs AT BU DOT EDU>
Sent by: "ADSM: To: ADSM-L AT VM.MARIST DOT EDU
Dist Stor cc:
Manager" Subject:
<[email protected] Re: Very slow restores
(days), hours to locate files
T.EDU>
07/06/2005 10:30
AM
Please respond
to "ADSM: Dist
Stor Manager"
Please, everyone, when posting questions about restorals, give details about
the manner in which the restoral was invoked so that we
can get a sense of what kind is involved (NQR, Classic) and what is involved.
Now... Robin, have a look at IBM Technote 1209563, which I ran across in doing
research yesterday. I recall such long-duration-
restores in the past, and as I recall they have involved the factors noted in
the Technote. LTO is also known for backhitch delays,
so that's another contributor in positioning on tape.
Richard Sims
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Very slow restores (days), hours to locate files, Robin Sharpe
- Re: Very slow restores (days), hours to locate files, Robin Sharpe
- Re: Very slow restores (days), hours to locate files, Robin Sharpe
- Re: Very slow restores (days), hours to locate files, Connor, Jeffrey P.
- Re: Very slow restores (days), hours to locate files, Robin Sharpe
- Re: Very slow restores (days), hours to locate files, Connor, Jeffrey P.
|
|
|