I have found that single drive reclamation can get into a loop when a file
is encountered that is larger than the interim storage pool. For example,
tape reclamation writes the contents of reclaimable tapes to a sequential
volume on disk. If the contents of the tape is a fragment of a file that is
continued on additional tapes, a sequential storage pool shortage occurs.
When *SM finishes reclamation for this tape (and the volumes needed for this
file) it pauses and once again has a look at what volume should be next to
reclaim. Then, starts the process again at the same tape/file. And again.
And again.
Maxfilesize in the storage pool is not an option. So, I have bypassed single
file reclamation (ie: gone back to tape to tape) for the time being to get
around this nasty file. I intend to revert back to single file reclamation
in the near future. However, you can be sure this nasty file will come
around again. Or, a similar sized file will do the same.
I want to find out what these large files are and where they came from.
Then, I can do some analysis as to what should really be done about this
situation. I am hesitant to launch an SQL select against the contents
database table. Has anyone found a way to determine the largest file(s) in
*SM's inventory?
John G. Talafous Sr. Tech. Prog/Anal
The Timken Company Phone: (330)-471-3390
P.O. Box 6927 Fax : (330)-471-4034
1835 Dueber Ave. S.W.
Canton, Ohio USA 44706-0927
[EMAIL PROTECTED] http://www.timken.com/
