I upgraded one server to 5.3.1.3 a couple of weeks ago.
Had one occurance of something similar; only my reclaim just said
"internal server error" and died.
Restarting reclaim didn't fix it.
But my reclaim was appending data to a "filling" tape that was almost
full.
I directed it to a different tape with MOVE DATA instead of reclaim, and
it finished OK.
Have seen nothing else strange.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
PAC Brion Arnaud
Sent: Thursday, September 15, 2005 9:10 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Space reclamation error for volumes dedicated to directory
structure storage ....
Hi all,
Since upgrade to TSM 5.3.1, I'm facing a strange problem affecting
reclamation on specific copypool dedicated to directories structure.
What happens is as follows :
09/15/05 09:34:28 ANR0984I Process 375 for SPACE RECLAMATION
started in the
BACKGROUND at 09:34:28. (PROCESS: 375)
09/15/05 09:34:28 ANR4931I Reclamation process 375 started for
copy storage
pool COPYLTO2_DIR automatically, threshold=70,
offsiteRclmLimit=No Limit, duration=None.
(PROCESS: 375)
09/15/05 09:34:28 ANR1040I Space reclamation started for volume
000559,
storage pool COPYLTO2_DIR (process number
375). (PROCESS:
375)
09/15/05 09:35:19 ANR8337I LTO volume 000507 mounted in drive
LTO2DR7
(/dev/rmt23). (PROCESS: 375)
09/15/05 09:35:30 ANR1340I Scratch volume 000507 is now defined
in storage
pool COPYLTO2_DIR. (PROCESS: 375)
09/15/05 09:35:30 ANR0513I Process 375 opened output volume
000507.
(PROCESS: 375)
09/15/05 09:55:04 ANR1173E Space reclamation for offsite
volume(s) cannot
copy file in storage pool DISKPOOL_DIR: Node
XXXXX,
Type Backup, File space \\XXXXX\i$, fsId 5,
File name
\SMSPKGI$\PAC00055\BW\PLANNING\ MAP. (PROCESS:
375)
09/15/05 09:55:04 ANR0102E asalloc.c(8720): Error 1 inserting row
in table
"AS.Segments". (PROCESS: 375)
.... Snipped, lots of ANR1173/ANR0102 errors ..........
I already spoke with IBM, and they told me to issue "REPAIR stgvol"
command against the volume being reclamed :
09/15/05 12:22:50 ANR2017I Administrator XXXXX issued command:
REPAIR
STGVOLS voln=000559 (SESSION: 54405)
09/15/05 12:22:50 ANR0984I Process 387 for REPAIR STGVOL started
in the
BACKGROUND at 12:22:50. (SESSION: 54405,
PROCESS: 387)
09/15/05 12:22:50 ANR4752I REPAIR STGVOL process 387 started for
1 volumes.
(SESSION: 54405, PROCESS: 387)
09/15/05 12:23:24 ANR4757I REPAIR STGVOL finished evaluating
volume 000559,
no repair was needed. (SESSION: 54405,
PROCESS: 387)
09/15/05 12:23:24 ANR4754I REPAIR STGVOL process 387 ended,
processed 1 of 1
total volumes with 0 repaired. (SESSION:
54405, PROCESS:
387)
09/15/05 12:23:24 ANR0987I Process 387 for REPAIR STGVOL running
in the
BACKGROUND processed 1 items with a completion
state of
SUCCESS at 12:23:24. (SESSION: 54405, PROCESS:
387)
So, it looks like the volume is OK.
It's now the second time within 2 weeks that this happens (on different
volumes, but always for that storage pool), and I can't figure out what
the problem is.
Someone having an idea ?
Just for info : if I kill the reclamation process and let it
automatically start again (even without performing repair stgvol), I
don't get any error anymore ...
Cheers.
Arnaud
************************************************************************
******
Panalpina Management Ltd., Basle, Switzerland, CIT Department
Viadukstrasse 42, P.O. Box 4002 Basel/CH
Phone: +41 (61) 226 11 11, FAX: +41 (61) 226 17 01
Direct: +41 (61) 226 19 78
e-mail: arnaud.brion AT panalpina DOT com
************************************************************************
******
|