Andy,
Thanks for the update. I knew about that command; I use it frequently
against specific volumes - that's how the ones on the shelf got to
"unavailable". I thought setting it for the entire storage pool would
accomplish the same thing.
Have a great holiday.
Tab
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 12/22/2004
10:12:23 AM:
> Hi Tab,
>
> If you review the TSM Administrator's Guide, you'll see in the chapter
> that talks about "Managing Storage Pools and Volumes" the following
> description for storage pool access modes:
>
> "User operations cannot get access to volumes in the storage pool. No
new
> writes are permitted to volumes in the storage pool from other volumes
> outside the storage pool. However, system processes (like reclamation)
are
> permitted to move files within the volumes in the storage pool."
>
> If you want to prevent access to any volumes in this pool, even for
> reclamation, then you might be able to use something like this:
>
> update volume * access=unavailable wherestgpool=migrpool
>
> Regards,
>
> Andy
>
> Andy Raibeck
> IBM Software Group
> Tivoli Storage Manager Client Development
> Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
> Internet e-mail: storman AT us.ibm DOT com
>
> The only dumb question is the one that goes unasked.
> The command line is your friend.
> "Good enough" is the enemy of excellence.
>
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 12/22/2004
> 08:02:22:
>
> > TSM Server 5.1.9.0 on AIX 5.2
> >
> > I am running copypool reclamation. Some of my primary tapes are
stored
> on
> > the shelf with access = unavailable. Because there are large files
that
> > span tapes, I'm seeing where TSM is loading the first tape of the set,
> > reaching its end, finding the second tape unavailable, and aborting
> > reclamation; only to repeat the entire process a minute later and
never
> > moving past.
> >
> > In an attempt to control that behavior, I set the entire primary
storage
> > pool to access = unavailable. Yet when copypool reclamation
restarted,
> it
> > again loaded the first tape of that set and repeated the process I
cited
> > earlier.
> >
> > How is that possible? I thought the whole point of setting access =
> > unavailable was to tell TSM to not even TRY to use that storage pool.
> Here
> > are the storage pool properties:
> >
> > tsm: >q stg migrpool f=d
> >
> > Storage Pool Name: MIGRPOOL
> > Storage Pool Type: Primary
> > Device Class Name: DEV05
> > Estimated Capacity (MB): 14,361,230.5
> > Pct Util: 16.9
> > Pct Migr: 19.7
> > Pct Logical: 99.4
> > High Mig Pct: 100
> > Low Mig Pct: 99
> > Migration Delay: 0
> > Migration Continue: Yes
> > Migration Processes:
> > Next Storage Pool:
> > Reclaim Storage Pool:
> > Maximum Size Threshold: No Limit
> > Access: Unavailable <===============
> > Description: Old data pool
> > Overflow Location: Local storage shelves
> > Cache Migrated Files?:
> > Collocate?: No
> > Reclamation Threshold: 100
> > Maximum Scratch Volumes Allowed: 300
> > Delay Period for Volume Reuse: 2 Day(s)
> > Migration in Progress?: No
> > Amount Migrated (MB): 0.00
> > Elapsed Migration Time (seconds): 0
> > Reclamation in Progress?: No
> > Volume Being Migrated/Reclaimed:
> > Last Update by (administrator): TTREPAGN
> > Last Update Date/Time: 12/22/2004 08:30:38
> > Storage Pool Data Format: Native
> > Copy Storage Pool(s):
> > Continue Copy on Error?:
> > CRC Data: No
> >
> > tsm: >
> >
> > TIA
> >
> > Tab Trepagnier
> > TSM Administrator
> > Laitram, L.L.C.
|
