Hi Wanda:
Yes, not a big problem but since we do have the resources we prefer to have 
each server node isolated to specific volumes for faster file recovery and 
recreation of backups in the event a volume becomes defective.

>>> Wanda.Prather AT JHUAPL DOT EDU 04/26/00 10:18AM >>>
It still happens.  If for any reason the tape containing data for node A is
unavailable at migration time (in use by another process, such as restore,
or the mount fails for any reason...) then TSM will put the data on a
different tape.  Usually on a new SCRATCH tape, but if that mount fails for
any reason, or if you have already reached MAXSCRATCH for the storage pool,
*SM will still put the data on an existing tape rather than fail the
migration.  One night of mount problems, or a day when you hit your
MAXSCRATCH for the storage pool, can result in several tapes with data for
mixed nodes.

Generally not something to worry about.  The next time this tape goes
through reclaim, TSM will collocate the output and everything will be
cleaned up again.  Just keep an eye on your MAXSCRATCH settings so it
doesn't happen too often.

************************************************************************
Wanda Prather
The Johns Hopkins Applied Physics Lab
443-778-8769
wanda_prather AT jhuapl DOT edu 

"Intelligence has much less practical application than you'd think" -
Scott Adams/Dilbert
************************************************************************




> -----Original Message-----
> From: Lawrence Clark [SMTP:Larry_Clark AT THRUWAY.STATE.NY DOT US] 
> Sent: Wednesday, April 26, 2000 8:32 AM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: Co-location?
>
> Hi Paul:
> Yes, my understanding of co-location agrees with yours, but we in fact do
> have more tapes than nodes and a pool of scratch tapes. Our 1st backups on
> the NT side are to disk based storage which are migrated to the tape
> library storage pool where co-location is in effect. During that process
> there are multiple mounts and my assumption until checking was that
> co-location was occurring by node.
>
> We do have nodes that have more data than can be held on one cartridge,
> but again, my assumption would be that another cartridge would be added
> from the scratch pool.
>
> Larry Clark
>
> >>> vkm AT CORNELLC.CIT.CORNELL DOT EDU 04/25/00 04:09PM >>>
> At 03:48 PM 4/25/2000 -0400, you wrote:
> >Hi:
> >I'm puzzled. We have a storage pool with co-location set on, yet after
> querying the volume usage table it suggest more than one node is stored on
> a given volume. Anyone hazard a guess as to why?
>
> Hi Larry,
>   Collocation does not guarantee that only one node will be stored per
> volume.  For example, if you have more nodes than volumes, then ADSM will
> have to put multiple nodes on a volume.  What collocation does is to
> strive
> to collocate data from one node on as few volumes as possible.  This is
> implemented during migration, reclamation, and move data.  When an output
> volume is selected by one of these processes, it will preferrentially
> select a volume that already has data from that node on it.
>   If you happen to have more tapes than nodes, and no node fills more than
> one tape, then you will only see 1 node per tape.
>
> ..Paul
>
>
> --
> Paul Zarnowski                         Ph: 607-255-4757
> 747 Rhodes Hall, Cornell University    Fx: 607-255-8521
> Ithaca, NY 14853-3801                  Em: psz1 AT cornell DOT edu