Hello Colleagues,
I have found all answer to my questions. And from my point of view are very
interesting and I would like to share with all TSMpeople.
1.- When one volume is reclaimed in this pool ( Pool with CG). How TSM does the
reclamation? moving files from one node from Volume to Scratch one or TSM moves
all nodes in the CG at the same time without distinction ?
---- it moves it from all nodes
2.- When TSM restores files from these tapes. Does it restore all files in a
sequential way ?. I mean TSM is reading the tape from the beginning and if it
finds files to belong to this TSM Client from different directories it restores
independently of the directory which this files belong or TSM server prepares
a list of file and it is looking one per one in the tape... or Which is the
procedure ?
----- it restores sequentially - so that it minimizes the tape movement.
3.- In case of migration, if we don't have CG TSM migrates files per node. What
happens if we have CG, it is per node or per CG ?
---- per CG
4.- In case we have a lanfree backup with 4 parallel sessions , is CG suitable
for this TSM Clients ?
---- sure, the better question is do they have enough data being written to
keep the tapes streaming, versus the advantages of writing to disk.
5.- Last question, in order to restore the client node. Are there differences
between these procedure and multiplexing competitors ones ? ...
--- yes. for multiplexing, they have to rebuild each individual file. THis
causes lots of tape positioning, and additional process to rebuild the files.
Multiplexing has a very large NEGATIVE impact on restore times.
Regards,
Fran
----- Mensaje original ----
De: Wolfgang J Moeller <moeller AT GWDG DOT DE>
Para: ADSM-L AT VM.MARIST DOT EDU
Enviado: mar,16 marzo, 2010 00:07
Asunto: 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
|
