Hi,
Isn't reading IBM docs fun!
> => does this really mean, that when one client is flooding my staging pools
> the migration processes becme concurrent to new data that is written directly
> to the NEXTSTGPool, because the first pool is full? if the next pool has a
> limited
>number of mount points (e.g. tape drives) this will cause the next, eben
>bigger problem.
In the "normal" tsm setup you make your disk pool big enough to hold a nights
worth of backups (or whatever your backup windows is).
Then in the day (backups not running) you migrate from the disk pool to the
NEXTpool (tape, datadomain), emptying the disk pool. Repeat every day.
If the disk pool runs out of space, TSM will attempt to send files directly to
the nextpool.
This situation will flood your tape drives. You really don't want this to
happen.
If you specify a file size limit on the disk pool, files bigger than the limit
go directly to the
next pool. Yes, this uses some/many tape drives, and you can run out. Think
of this
option as protecting your disk pool for being flooded by really big backups, or
a
way to keep the size of your disk pool down.
This is a resource balancing act that you have to watch and tune for your
environment.
How big to make your disk pool.
How many tape drives you have available.
Enough tape drives, disk bandwidth and time to empty the disk pools.
Enough tape drives, disk bandwidth and time to update copy pools.
There's no one right answer . . . .it depends!
Rick
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
bjoern.nachtwey AT gwdg DOT de
Sent: Wednesday, April 16, 2014 2:37 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Question about "Storage hierarchy"
Dear all,
switching to an new employer allows me to read all^H^H^H some of IBM's
documentation about TSM ;-)
inside the server documentation there's a short description on "Example:
How the server determines where to store files in a hierarchy" [1].
within this there's written:
"If the DISKPOOL storage pool has no maximum file size specified, the server
checks for enough space in the pool to store the physical file.
If there is not enough space for the physical file, the server uses the next
storage pool in the storage hierarchy to store the file."
=> does this really mean, that when one client is flooding my staging pools the
migration processes becme concurrent to new data that is written directly to
the NEXTSTGPool, because the first pool is full? if the next pool has a limited
number of mount points (e.g. tape drives) this will cause the next, eben bigger
problem.
if so, what's the best practise to empty the staging pool?
- setting a max filesize does not solve the problem, especially if there are
many files
- perhaps "DISABLE SESSIONS CLIENT" -- this seems to be no really good answer
:-(
Thanks & best regards,
Bjørn
[1]
http://pic.dhe.ibm.com/infocenter/tsminfo/v7r1/index.jsp?topic=%2Fcom.ibm.itsm.srv.doc%2Ft_volume_seq_define.html
[1] http://tinyurl.com/p23j5eo
--
Bjørn Nachtwey <mailto:bjoern.nachtwey AT gwdg DOT de>
Arbeitsgruppe IT-Infrastruktur Tel. +49 551 201-2181
----------------------------------------------------- G W D G ---- Gesellschaft
für wissenschaftliche Datenverarbeitung mbH Göttingen Am Fassberg 11, 37077
Göttingen
E-Mail: gwdg AT gwdg DOT de Tel.: +49 (0)551 201-1510
URL: http://www.gwdg.de Fax: +49 (0)551 201-2150
Geschäftsführer: Prof. Dr. Ramin Yahyapour
Aufsichtsratsvorsitzender: Dipl.-Kfm. Markus Hoppe
Sitz der Gesellschaft: Göttingen
Registergericht: Göttingen Handelsregister-Nr. B 598
-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If
the reader of this message is not the intended recipient or an
agent responsible for delivering it to the intended recipient, you
are hereby notified that you have received this document in error
and that any review, dissemination, distribution, or copying of
this message is strictly prohibited. If you have received this
communication in error, please notify us immediately, and delete
the original message.
|
