>> On Mon, 17 Nov 2008 13:00:09 -0500, Paul Zarnowski <psz1 AT CORNELL DOT EDU> 
>> said:
> At 12:50 PM 11/17/2008, Allen S. Rout wrote:
>> >> On Mon, 17 Nov 2008 11:09:55 -0500, Paul Zarnowski <psz1 AT CORNELL DOT 
>> >> EDU>


>> But I'm going to claim you don't want to do this, and the bandwidth
>> utilization is in fact the optimal solution.  The alternative,
>> building new volumes, is going to waste a -lot- of local tape time.
>> Each offsite reclamation process you go through, you're going to (to a
>> good appoximation) mount every single primary tape in your library.
>> Calculate mount delay * nvols as an absolute -floor- of wasted tape
>> hours per reclamation attempt.  And then your access is far from
>> optimal.  Lots of seek-read -- seek-read.  My offsite reclamation runs
>> persist for days and days.

> You lost me.  We were planning to collocate by group on both primary
> and copy volumes.  It seems to me that reading from primary volumes
> should be just as fast as reading from copy volumes, but that
> reading from the copy volumes would be reading over the WAN.
> Perhaps collocating the copy volumes is not a good idea?  It seemed
> like a good idea at the time.

Mmmm, I see your point, and I agree.  If the local and the remote
volumes are both collocated in the same way, then my mount-thrashing
behavior is attenuated enough to neglect.

So, if you want to treat the virtually-remote volumes as offsite in
TSM parlance, then I bet you will have to go through all the DRM
volume location manipulation behavior.  In fact, you're probably going
to have to micromanage it a lot.  For example, the same volume you'd
like to be 'Offiste' when you decide to reclaim it, you want to be
online all the rest of the time, so you don't have delays when you
want to read it, or append to it.

I still have the aesthetic opinion that you'd be better off using the
network here-and-back to maintain those, than doing a lot of custom
work.  I can see a lot of edges you might run into.  Mmmm, white
paper.

- Allen S. Rout