Re: Client Session Stuck in MEDIAW Status During Migration
1998-03-18 11:43:45
I've seen this situation occur with our disk pools as well. What
seems to happen is a) the disk pool fills up (100% or very near
to it), b) migration begins, c) sessions targeted for the filled
disk pool now need to go to tape, b/c disk pool is full, so they
go into MediaW state.
Once (c) has happened, and the session has requested a tape,
there seems to be no going back to the disk pool for that
session, even if migration brings you back down to 0%
utilization.
I'd like to see this changed such that the session will
reconsider the disk pool once migration has brought it down under
the "High Migration %" value.
-- Tom
"It's a dog eat dog world, Thomas A. La Porte
and I'm wearing milkbone underwear." DreamWorks SKG
- Norm Peterson <tlaporte AT anim.dreamworks DOT com>
On Wed, 18 Mar 1998, Jeff Connor wrote:
>I have a problem that comes up from time to time that I was wondering if
>anyone else has experienced the same thing during disk to tape storage pool
>migrations. My ADSM environment is as follows:
>
>ADSM MVS Server V2.1.10 running on OS/390 V1R2.
>TCPIP for MVS V3.2
>Client is HP-UX V10 running V2.1.6 of the ADSM Client
>80GB disk storage pool migrated to Magstar 3590's in an STK Silo daily by
>setting hi and lo thresholds to zero.
>Disk pool migration thresholds are set at hi=95 lo=75 during the night.
>
>The scenario is our disk pool fills up during the nightly backups and
>migration begins. Last night we got as high as 99.2% utilized while
>migrations were running. The problem, aside from having a disk pool that
>is currently undersized, is that some client backup sessions show a status
>of mediaw indefinitely. I can understand that occurring initially when the
>disk pool is 99+% full. I mean hey there's no place for the data to go
>right? The problem is that even when the pool utilization drops to say
>under 60% the sessions that showed mediaw still are stuck/not running still
>showing a status of mediaw even though there appears to be plenty of space
>available in the disk pool. Does anyone know why these sessions are
>hanging in a mediaw state and don't just start running as space becomes
>available as data migrates from disk to tape? I thought of setting the
>high migration value to a lower number like 80 for example thinking that if
>migration started before we reached such a high utilization factor it
>might avoid the apparent "gridlock". Even if that fixes the problem it
>still doesn't explain why the sessions hang in mediaw state indefinitely
>and have to be eventually canceled even though space does become available
>as data is migrated. Any ideas?
>
>Jeff Connor
>Niagara Mohawk Power
>Syracuse, NY
>
|
|
|