Disable cache + empty disk pool (pct util = 0%!)

[nicflatterie]

Greetings, a client of mine as a TSM on which cache was set to yes for the primary disk pool. All is well but the client does not understand that the "pct util" is not equal to 0% after migration occurs. I am tired of this, and want to turn off cache. But...

- change cache to no
- migrate files (lo=0 to migrate them all and migdelay = 0 so not wait)

now how do I empty the disk volumes? I do not want the cached files in there anymore. I searched quite a lot and cannot seem to find that... Is my only option to flush the volumes and create new ones?

Thanks, Nic.

 

[moon-buddy]

Greetings, a client of mine as a TSM on which cache was set to yes for the primary disk pool. All is well but the client does not understand that the "pct util" is not equal to 0% after migration occurs. I am tired of this, and want to turn off cache. But...

- change cache to no
- migrate files (lo=0 to migrate them all and migdelay = 0 so not wait)

now how do I empty the disk volumes? I do not want the cached files in there anymore. I searched quite a lot and cannot seem to find that... Is my only option to flush the volumes and create new ones?

Thanks, Nic.

Add hi=0 and all of the data on disk will be moved over to the backup (not offsite pool but next defined pool) online tape pool.

Reset back to hi=70, lo=40 or something else as you wish after the migration.

 

[nicflatterie]

nope!

Tried that. The cached files are still in there so my volumes are not 0%...

 

[rore]

Hi
Try backing up just some files on a node who backups to your disk pool. Then run migration (migrate stgpool).

The migration process shold get rid of the cache files as the pool is not cached enabled anymore.

Rudy

EDIT just found this http://www-01.ibm.com/support/docvi...ol&uid=swg21198169&loc=en_US&cs=utf-8&lang=en
and this
http://www-01.ibm.com/support/docvi...ol&uid=swg21322468&loc=en_US&cs=utf-8&lang=en

 

[lidra]

Run Expire Inventory. If you have an administrative schedule that runs expiration only for a defined time (ex 2 hours) then expiration didnt get to them yet (might never get there).

The objects that are in the storage pool are a copy of what was already migrated to the next storage pool (tape). Because of that the objects will not be migrated a second time, and migration will not touch them.

I would believe expire Inventory should empty the space on that storage pool. Another thing would be to leave them as is, as the server should overwrite them in time when new objects come into the storage pool.

Cheers,

Lidra

 

[lidra]

Hi
Try backing up just some files on a node who backups to your disk pool. Then run migration (migrate stgpool).

The migration process shold get rid of the cache files as the pool is not cached enabled anymore.

Rudy

EDIT just found this http://www-01.ibm.com/support/docvi...ol&uid=swg21198169&loc=en_US&cs=utf-8&lang=en
and this
http://www-01.ibm.com/support/docvi...ol&uid=swg21322468&loc=en_US&cs=utf-8&lang=en

Ok, I was wrong, expiration doesn't delete them.
It doesnt make sense for me why not.....but you learn something new every day.

Cheers,

Lidra

 

[BBB]

You have to either delete the stgpool vols ... or fill them up with something else to overwrite the cached copies.

(or the cached copies will gradually expire over time when that file is expired from tsm - could be a long time though!)

 

[rore]

You have to either delete the stgpool vols ... or fill them up with something else to overwrite the cached copies.

(or the cached copies will gradually expire over time when that file is expired from tsm - could be a long time though!)

No need to delete the stgppols vols. If you don't have something to fill them up and don't want to wait for them to expire:

http://www-01.ibm.com/support/docvi...ol&uid=swg21322468&loc=en_US&cs=utf-8&lang=en

Rudy

 

[nicflatterie]

My solution

I solve this situation finally. I migrated all to tape, deleted all disk volumes with discard=yes and recreated them, making sure the cache parameter was now set to no.

The client is now convinced that migration worked. Remember this all started with a client that had a poor understanding of TSM's internal workings and would not trust my word on it.

Thanks for all the replies!

 

[Kramer]

You should have been able to flush the disk pools by first migrating all the current data...
MIGRATE STG backup_storage_pool LO=0
Then using something like this for each volume in the disk stg pool to remove the cached files...
MOVE DATA X:\BACKUP_STG_POOL_VOLUME1.DSM WAIT=NO

 

[Patthecat]

Hi guys,

I had this problem with 7.1.7.


The situation
The situation was, that you had stg_pool cached option = yes and set to no, but nothing happens.
The migrate stg poolname lowmig=0 - command says: ANR4924I MIGRATE STGPOOL: Migration is not needed for the storage pool.

The solution/Workaround:
Look up and notice, what the next-pool of the disk-pool is.
Now go to the private volumes of the disk-pool, you would like to empty.
Select every volume and "move data to another storage pool", this must be the old "next-pool"
You will see, that migration happens in a few minutes and every single volume will have a utilization of 0%.

Reason:
I think, that every cached copy is in the next pool and so, TSM has nothing to move!

Now you can delete the volumes from the storage-pool, if you want.

kind regards
Pat

 

[[email protected]]

You should have been able to flush the disk pools by first migrating all the current data...
MIGRATE STG backup_storage_pool LO=0
Then using something like this for each volume in the disk stg pool to remove the cached files...
MOVE DATA X:\BACKUP_STG_POOL_VOLUME1.DSM WAIT=NO

YES. This is the solution. Thanks a lot Kramer. (12 years later, still useful)