The "one file over N tapes" problem can be avoided only if such files are 
separated in own storage pool through different copygroup destination. 
Afterwards you have two options:
- run reclamation weekly or monthly
- not reclaim at all - on version expiration all tapes except the first 
and the last will go to scratch. First and last tape will contain 
aggregates from no more than two files. When second file's version expire 
the tape will also go to scratch.

Zlatko Krastev
IT Consultant






Stefan Holzwarth <stefan.holzwarth AT ADAC DOT DE>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
26.08.2003 17:35
Please respond to "ADSM: Dist Stor Manager"

 
        To:     ADSM-L AT VM.MARIST DOT EDU
        cc: 
        Subject:        Findings with Migration and  bad Reclamation behavior


Today I took a closer look at how often and how much data is reclaimed and
migrated.

Since upgrade of on of our primary stgpool to 700 GByte  2 month ago we
could establish a migdelay of  8 days.
Together with our standard policy (1 active + 3 inactive and 60 days keep
for last deleted) we could reduce the migration amount from
100% to 30% of daily backup volume for that pool (120 small NT server):
(All nodes with name NT% go to BACKUPPOOL)

'select sum(bytes)/(1024*1024*1024) as GBYTE from adsm.summary where
activity = 'BACKUP' and entity like 'NT%' and end_time >= 
current_timestamp
- 14 days'
Result: 2188
'select sum(bytes)/(1024*1024*1024) as GBYTE from adsm.summary where
activity = 'MIGRATION' and entity = 'BACKUPPOOL' and end_time >=
current_timestamp - 14 days'
Result: 593

In the past these 2 values where the same for each day.... 

My next hope was that the reclamation for the nt nodes should also
significantly have been reduced.
But I could not find a really significant decrease - maybe I have to wait 
a
little longer for that process

But what I found was the following: 
I have from time to time reclamation processes that move more than 3 times
of the capacity of one 3590 tape !!!!!! i.e.
08/21/2003 11:43:21 ANR0986I Process 199 for SPACE RECLAMATION running in
the BACKGROUND processed 1 items for a total of 33.007.866.134 bytes with 
a
completion state of SUCCESS at 11:43:21. 

The reclamation process put 1 large file spread over 4 tapes onto 4 new
tapes and scratching the old ones. 
The reason seems to be the reaching of the reclamation threshold (80%) on
one of the 4 tapes. 

Has anyone similar problems? 
How can I avoid that the reclamation process keeps 2 units for hours?

Kind regards,

Stefan Holzwarth

----------------------------------------------------------------------------
--
Stefan Holzwarth
ADAC e.V. (Informationsverarbeitung - Systemtechnik - Basisdienste)
Am Westpark 8, 81373 München, Tel.: (089) 7676-5212, Fax: (089) 76768924
mailto:stefan.holzwarth AT adac DOT de