ADSM-L

Re: [ADSM-L] Collocation Groups Reclamation and Restore

2010-03-15 19:07:56
Subject: Re: [ADSM-L] Collocation Groups Reclamation and Restore
From: Wolfgang J Moeller <moeller AT GWDG DOT DE>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 16 Mar 2010 00:07:13 +0100
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