Laura Lantz is no longer with OBI. Please send email to the following
address and/or remove her from your distribution list. This mailbox
will be closing effective March 18. Thank you.
Laura's email address is: laurakev13 AT yahoo DOT com
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Wolfgang J Moeller
Sent: Monday, March 15, 2010 6:07 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Collocation Groups Reclamation and Restore
Fred Johanson writes:
> > Once a tape has been mounted for a collocation group's data,
> > all nodes in that group are migrated.
> > At least when the source pool is of type DISK, I'd guess
> > that files will still be ordered by filespace and node,
> > just like they are by filespace in the case of collocation by node.
>
> Not always. I often find volumes with a few inches used belong to a
client
> belonging to a CG residing on another volume. It certainly looks as
if
> files ready for migration find the desired volume in use by another
member
> of the CG, so they go to scratch.
>
> As for reclamation, this morning I removed a client. 2 of its volumes
> popped to the top of the list of reclamation candidates (2 reclamation
processes).
> One went to the expected collector. The second went to scratch.
OK, I meant _normally_ (that is to say, when I'm watching).
Rarely, I believe the same thing to happen here (we regularly run
two migration processes in parallel). TSM Server 5.5.2.1, btw.
I do manually clear out a few "duplicate filling" volumes per week &
server,
but then there are several more possible reasons, among them routine
changes
to collocation groups (new nodes getting backed up w/o being assigned a
group,
nodes removed from a group when they get too large).
Occasionally I do see a filling volume with a large amount of data on it
not being written to for a couple of days, while new data menawhile goes
to a less occupied volume - in violation of the rule that the "fullest"
tape
was chosen first. Just another very-low-priority TSM bug, I'd guess ...
Lately, I also discovered "phantom volumes":
Filling, not appearing in any node's Q NODEDATA, no contents according
to
Q CONTENTS; but invariably MOVE DATA would find & move around some 2..3
files
totalling a few Mbytes.
Likely you have to REMOVE NODE more often than the average TSM operator,
in order to see such things. [You'd also better(?) have some tool
in addition to TSM SELECT in order to spot all of this weirdness. ;-]
Best regards,
Wolfgang J. Moeller <moeller AT gwdg DOT de>
Tel. +49 551 201-1516 ... not representing ... GWDG, Goettingen, Germany
|