Imperfect collocation occurs when collocation is enabled, but there are
insufficient scratch tapes to maintain 100% separation of data. For
example, if you have five nodes but only four scratch tapes in the pool
and collocation by node is enabled, then volumes will be shared to some
extent by the nodes (assuming that the capacity of the tapes is not at
issue). Perhaps data from nodes one, two, three, and four reside on one
each of the four tape volumes, but then node five's data will co-reside
with at least one other node's data. Hence "Imperfect" collocation. Note:
I do not know where I heard this term (can't find it in the book), but I
do not think I made it up.
For more info, see the Admin Guide chapter "Managing Storage Pools and
Volumes", section "Keeping a Client's Files Together: Collocation",
subsection "How the Server Selects Volumes with Collocation Enabled".
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
David Nicholson <David_R_Nicholson AT WHIRLPOOL DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
05/05/2004 05:33
Please respond to
"ADSM: Dist Stor Manager"
To
ADSM-L AT VM.MARIST DOT EDU
cc
Subject
Andy.....What is Imperfect Collocation???
"Imperfect Collocation"??? My experience has been that when I reach the
maxscratch threshold the storage group is full and cant accept data. Am I
missing something??
Dave Nicholson
Whirlpool Corporation
Andrew Raibeck <storman AT US.IBM DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
05/04/2004 07:09 PM
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: What ever happened to Group Collocation ?
Zoltan,
I don't know what you were specifically told about the new feature, but
keep in mind that any such disclosures are usually with the caveats
"subject to change". :-)
To the best of my knowledge this is currently targeted for our next major
release this fall. (Caveat: This statement does not represent a formal
announcement or commitment, and is subject to change.)
As others have suggested, check the tape utilization for your smaller
nodes and consider using imperfect collocation (reduce MAXSCRATCH which
will allow multiple nodes to share a tape).
Some other thoughts:
- Make sure your tapes are available to the server for additional writes,
i.e. not in read-only or other access state that prevents appending data
to the tape.
- Check the status of the tapes to make sure they aren't full. If they are
full, then maybe you need to run reclamation?
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
05/04/2004 13:13
Please respond to
"ADSM: Dist Stor Manager"
To
ADSM-L AT VM.MARIST DOT EDU
cc
Subject
Re: What ever happened to Group Collocation ?
I have already thought of this idea. I was hoping for GROUP COLLOCATION.
The problem with this idea/design is I have to essential duplicate
*EVERYTHING*, such as admin processes, operator training, etc. Also, this
means I have to set aside disk storage (which is very limited on my zOS
system) to dedicate for each pool, that can't be shared, and hope I don't
guess wrong on how much each pool/group needs.
Thanks for the suggestions. Unfortunately, this is probably the way I
will have to go.
One confusion is why do I have sooooo many partially filled tapes ? I
don't have this many nodes ?
|
