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:[EMAIL PROTECTED] On Behalf Of PAC Brion Arnaud Sent: Thursday, September 15, 2005 9:10 AM To: ADSM-L@VM.MARIST.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: [EMAIL PROTECTED] ************************************************************************ ******
