ADSM-L

Re: Question on scratch again.

1998-04-08 06:11:44
Subject: Re: Question on scratch again.
From: Matthew Warren <Matthew.Warren AT MARKS-AND-SPENCER DOT COM>
Date: Wed, 8 Apr 1998 11:11:44 +0100
If possible, I will always try to run movedata's instead of reclaim.
Your right, Lindsay it is more effective and also gives greater controll
over wich tapes are reclaimed.

Matthew Warren.
HOIST - Head Office Infrastructure Support Team.
ADSM (FAB) + Unix support.
        Marks & Spencer Plc.
        Baker Street.
        London.
Email: matthew.warren AT marks-and-spencer DOT com




> -----Original Message-----
> From: Lindsay Morris [SMTP:lhmorris AT US.IBM DOT COM]
> Sent: Tuesday, April 07, 1998 4:55 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: Question on scratch again.
>
> Don't set ADSM reclamation to 10% -  It'll spin tapes forever and not
> reclaim
> much space.
>
> It turns out that ADSM reclamation makes poor choices regarding which
> tapes to
> reclaim.
> If you have reclamation set to 60%, then tapes which are 40% full or
> less are
> candidates, right?
>
> So consider:
> if ADSM picks a tape which is 40% full, it'll take maybe 30 minutes to
> reclaim,
> and you'll only free up 60% of a tape.
> If ADSM picks a tape which is 1% full, it'll reclaim it in 3 minutes,
> and
> you'll regain 99% of a tape.
>
> Clearly, ADSM should start with tapes which are 1% full, and work its
> way up
> toward the tapes which are 40% full.  It would reclaim a lot more
> space a lot
> faster if it worked this way.
>
> But it doesn't do this.  Instead, it works off a list which is roughly
> ordered
> by total capacity of the tape and completely ignores the utilization.
>
> Two ways to get around this:
> 1. Use admin schedules to set reclamation to 95% at 6AM, 90% at 6:30,
> 85% at
> 7:00, etc.  Tacky, but....
> 2. Write a script which does a "Query Volume", sorts the output, then
> does
> "Move Data"s on the easiest one first.
> I did the latter - it's very effective.
>
> ADSM support understands this problem and has told me they will try to
> fix the
> behavior in some future release.
<Prev in Thread] Current Thread [Next in Thread>