ADSM-L

Re: reclaim of tape volumes

1998-11-04 21:43:14
Subject: Re: reclaim of tape volumes
From: Russell Street <russells AT AUCKLAND.AC DOT NZ>
Date: Thu, 5 Nov 1998 15:43:14 +1300
Rj Van Doggenaar said...

> Is there anyone who has experience running tape reclamation with a
> single drive unit ?

> Question is , how can I tell ADSM to unload the drive, migrate the
> data from reclamation pool to main storege pool, and then continue
> again reclaiming .

You don't have to, ADSM does it automatically.


[warning ... long rambling rant attached.]





With ADSM v3 you can set the storage pool you use to reclaim a volume

        update stgp TAPEPOOL RECLAIMSTGpool=DISKPOOL


When reclaim happens

ADSM will copy the data from the tape onto disk pool

When the disk pool fills up, the reclaim will fail.

By this time, the migration thresholds will have been exceeded.

There will now be a reclaim process started and waiting for a mount
point.

ADSM will unmount the tape it was reclaiming, mount the tape(s)
needed for migration

The migration process will run until it has the storage pool has
fallen under the threshold as normal

At the same time, ADSM will have rexamined the tape volumes.  It
will rediscover the tape it was reclaiming from, and spawn another job
to reclaim that tape.  The reclaim waits until the migration finishes.

When the migration completes, it will go back to step 1.


Quite possibly the reclaim process will be preempted by the migration
process.  There is a page in the admin guide on mount point
pre-emption and their relative priorities.  This means slightly less
data will be moved per round.



If you only have one tape drive, you are probably better off using
putting the reclaim threshold to 100% to disable automatic reclaims,
using

        MOVE DATA VOLUME stgp=DISKPOOL

and manually picking volumes that can be reclaimed without going
invoking a reclaimation.  You will have more control over your ADSM
server this way.  Or more work to do... I am a micro manager, so this
is fine ;)



This wonderful piece of SQL (adjusted to your local environment) will
tell you which volumes have less data on them than your disk pool:


select                                                   -
        volume_name                   as "Volume Name",  -
        cast(last_read_date as date)  as "Last Read",    -
        cast(last_write_date as date) as "Last Write",   -
        cast(est_capacity_mb*pct_utilized/100/1024       -
             as decimal(3,1)) as "Usage (GB)",           -
        cast(pct_utilized as decimal(3,1)) as "% Util"   -
  from volumes                                           -
  where stgpool_name       = 'DLTPOOL'                   -
        and   status       = 'FULL'                      -
        and (est_capacity_mb*pct_utilized/100) -         -
            (select est_capacity_mb*(100-pct_migr)/100   -
                    from stgpools                        -
                    where stgpool_name = 'BACKUPPOOL') < 0*1024


[I change the "0*1024" to (say) 3*1024 if I want to find volumes that
are close to the threshold.]

If you have applied the latest PTF, you can add "order by 4" to get it
sorted.  There are bugs in earlier SQL service that scrambles
cast( ... as DECIMAL/DATE) columns if you try to sort them.




As a general comment, for collocated tape pools automated reclaims are
really bad news if they go from tape to tape.

Consider a reclaimed volume that has only two nodes' data on it.  It
has been created over a period of (say) several weeks by adding files
to it every night.

And for argument's sake: new data for these two nodes now go to
different tapes.


When it comes to do the reclaim, the tape contents conceptually looks like:

    Files beloning to NODE1 for 1st day
    Empty spaces for deleted files from NODE1, 1st day
    Files beloning to NODE2 for 1st day
    Empty spaces for deleted files from NODE2, 1st day
    Files beloning to NODE1 for 2nd day
    Empty spaces for deleted files from NODE1, 2nd day
    Files beloning to NODE2 for 2nd day
    Empty spaces for deleted files from NODE2, 2nd day

and so on.



What happens when ADSM comes to reclaim this tape?

It can only work sequentially through the tape and deal with the data
it comes across in the order it arrives.

It finds the first node's data.  It says "that has to go to the tape
with the rest of NODE1's data".  Mounts tape.  Copies files.

Skips over the empty space.

Now finds files beloning to NODE2.  They have to go onto the tape with
NODE2's files.  So it unmounts the tape it just unmounted, mounts a
new tape and copies.

You could probably figure out what happens next :)

It is a pathological example to illustrate the phenomena.

This won't happen if you only have a few nodes, or more tapes than
active nodes.

Reclamining via a disk pool makes things much easier on your tape
drives and tapes.  Not to mention taking much less time because you
don't have to do lots of tape mounts.

Having one of those really nice IBM tape drives that mount and unmount
tapes in seconds would cut that down.  I have DLT drives; Mounts and
unmounts tapes in minutes <sigh>



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