ADSM-L

Space reclamation error for volumes dedicated to directory structure storage ....

2005-09-15 09:09:58
Subject: Space reclamation error for volumes dedicated to directory structure storage ....
From: PAC Brion Arnaud <Arnaud.Brion AT PANALPINA DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 15 Sep 2005 15:09:38 +0200
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
************************************************************************
******

<Prev in Thread] Current Thread [Next in Thread>