So, I've got some DB2 database backups on my TSM server.  For those of
you who aren't familiar with the way that app backs up, you have a
relatively small number of large files; we have one or two sessions
running, so we have one or two files when we're done.  This means my
DB fulls are rattling around in 200-500G single files.

So we back them up to an offsite copy pool.  Nice and easy.

Now, we happen to have one big primary stgpool on this TSM server.
This means that, as the stgpool backups happen, adjacent to every big
file is (most often) a bunch of little files.  These adjacencies
happen a random distance through a given offsite volume.

Consequently, if the _rest_ of the remote volume expires, I may have
to copy a 500G file in order to reclaim a 20G volume which had 200M of
the big file on it.  Ick.

It's especially irritating when I _know_ that I'm replacing (say) 20
20G volumes full of BIGFILE with a -different- 20 20G volumes full of
BIGFILE.  Reclaim, indeed.  Humph.


The cleanest way to handle these huge files, if I'd anticipated this
corner case when I started, would be to arrange for the big files to
be in their own separate storage heirarchy.  I'd never even reclaim
the copy stgpool volumes from there: It's not worth the extra motion.
I may still get around to doing that.


The perfect technical fix would be for TSM to do some navel gazing on,
say, files (aggregates?  are aggregates still involved with large
files?) larger than a configurable NAVELGAZESIZE.

While making offsite copy to a devclass of type SERVER:
 If next filesize > NAVELGAZESIZE
   close this volume, open a new one.

   copy copy copy copy

   when done, close this volume, open a new one.


it might even be rational to have NAVELGAZESIZE = devclass maxcap or
something.  But I like it settable.

I can't come up with a downside to this strategy: we already
proliferate offsite volumes for a bunch of bad reasons.  This isn't
much proliferation, and it's for a darn good reason.


I'm thinking of developing this into a formal feature request /
requirement / whatever.


- Allen S. Rout