----- Hans Christian Riksheim wrote: -----

>I am trying to understand what TSM does with reclamation of large files.
>We have a filepool of 10G-volumes and I see the TSM-server moving a 64G
>file during reclamation. This file is from an Exchange-backup.

>It seems to me that TSM moves the whole file to other volumes and not
>just the small part of it that was residing on a volume and causing the
>reclamation to start in the first place. A "q vol f=d" tells me that the
>current input volume during reclamation is full with no reclaimable
>space.

I think you are understanding the behavior correctly. My site used to see
exactly that behavior with 20 GB database backups and 10 GB sequential
volumes (admitedly tape volumes rather than file volumes).

>So for me this sounds a lot of waste of disk I/O. I am curiuos to know
>if there is a good reason for this behavior or how to avoid it(except
>creating larger volumes).

Offhand, I can think of two options for avoiding this behavior.

If the 64 GB files have a uniform retention period, as is typical of
database backups, you could give them their own storage pool and not
do reclamation for that pool, relying on expiration to empty volumes.

I suppose to could write a script to issue 'query content' commands
with 'format=detailed' and 'count=1' or 'count=-1', identify volumes
that could be reclaimed efficiently, and run 'move data' commands for
those volumes. The 'count=1' option would pick out the first file,
which might be continued from another volume, and 'count=-1' would
pick out the last file, which might continue onto another volume.