Expiration Issue

[johnnyp112]

Hi,
I'm running out of disk storage on a Windows version of TSM 5.5.1. I have 12.7 TB of sequential disk storage called FILEPOOL. I also have a primary BACKUPPOOL that is about 2.5 TB of disk storage. I do not have a COPYPOOL.

Both my FILEPOOL and BACKUPOOL is full. When I do a query:

SELECT * FROM FILESPACES

I see that my client nodes are only occupying about 7 TB. This leads me to believe that expiration is not running correctly. When I run the command EXPIRE INVENTORY, it only examines 123 objects and completes with SUCCESS.

For my Policy Domain, I did set it up so it keeps 5 versions for 180 days.

Any idea as to what is wrong and how to fix this?

Much appreciated.

Johnny

 

[moon-buddy]

The number of versions is chewing up space.

Reduce the number of versions and you can get back disk space.

 

[javajockey]

Are you running reclamation on your FILEPOOL? Even though it's random disk based, you still have to run reclamation on device class FILE. Also, If you have the space, can you increase the maxscratch ?

BTW, you would be a good candidate for 6.1 Since Devclass FILE can take advantage of Deduping on TSM 6.1!

 

[johnnyp112]

Yes, I am running reclamation on the FILEPOOL.

It just doesn't seem right that the EXPIRE INVENTORY only examines 123 objects.

 

[javajockey]

This may sound quite obvious to you but a 100G device class volume that's 61% Full will waste 39G. In other words it takes 100G of logical disk space even though TSM only has 61G of data on it.

Your clients may not be expiring any data.
post this

q copy f=d

backup some data on a client, then delete the data... backup again.
the log file on the client should suggest that the data has been expired.
Naturally, this will also depend on your retention settings (Retain only version)
If you never delete the only copy, It ill not be eligible for expiration therefor the object will not even be scanned.

If you really want to get serious, you could create a "test domain" with different copygroup settings.

 

[johnnyp112]

I dropped the versions from 5 to 3 and ran my expiration. Now the expiration process is running longer. I'll just have to double up on my storage and aim to upgrade to TSM 6.1.

Thanks all for the help.

Johnny

 

[BBB]

The number of objects examined by expiration is mostly related to how many inactive objects are stored on the server. If you have mostly active objects and not many inactive ones you could get a similar result to yours.

Also are you aware that by default a file pool will store files (or aggregates of files) in a minimum 256KB chunk of disk space? So you can have a single file, directory, or an aggregate of them that really are only 10KB, but use 256KB of disk space? If you have a large number of small files this may hit you. A "q occ" will show us how many files you have stored. The workaround is to use a pool with a "nonblock" format instead of native, for these types of files/dirs.