You can always perform a MOVE DATA on tapes that you detect have multiple
nodes on them. However, if you do this be aware that MOVE DATA will not
reclaim unused space in file-aggregates like RECLAIM will. In our
environment, we don't attempt to force one node per tape because we have
2000 nodes and only 300+ tapes. We get user data spread across 2 or 3
tapes sometimes, but that's not a real problem for us. If we didn't use
collocation, we'd end up with user data spread across possibly over a
hundred tapes or more, over time.
..Paul
--
At 11:39 AM 4/26/2000 -0400, you wrote:
At 11:39 AM 4/26/2000 -0400, you wrote:
>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
>
|
