Thomas,
Be aware that sequential pool to sequential pool migrates are single threaded.
If you are used to running multiple disk-> tape pool processes at the same
time, this could bite you when you are using a sequential disk pool, as your
migrates to tape will take longer for your larger pools.
This issue is slated to be fixed in an upcoming TSM release.
Steve.
Steve Harris
AIX and TSM Admin
Queensland Health, Brisbane Australia.
>>> Thomas.Denier AT MAIL.TJU DOT EDU 10/07/2004 0:56:50 >>>
We currently run a TSM 5.1 server under OS/390. We have our client
population divided among roughly twenty policy domains, each with its
own primary and copy tape pools. This is done primarily to allow for
reasonably fast restores without using an outlandish number of tapes
to support collocation by node. Because of the way migration works,
each policy domain also has its own disk storage pool used as the
initial destination for incoming backup data. As you would expect,
day to day variations in client workloads are a major nuisance. On any
given day a few disk pools will run out of space and spill to tape
during the backup window, and other disk pools will have sizable amounts
of unused space.
We are now preparing to migrate to a 5.2 server under mainframe Linux.
We are considering the following arrangement:
1.Use LVM to create a large (hundreds of gigabytes) file system.
2.Define a file device class using the large file system.
3.Create a sequential storage pool for each policy domain (to be used
as the initial destination for backups) using the file device class.
We are already aware of two potential problems: having the file device
class run out of space, and having processes hang waiting for access
to volumes when backups run late. Are there any other pitfalls we should
be aware of? In particular, what will happen when a client sends multiple
streams of backup data from the same filespace? Will the server mount
multiple volumes concurrently, or will it force the multiple streams to
queue up waiting for access to a single volume?
***********************************************************************************
This email, including any attachments sent with it, is confidential and for the
sole use of the intended recipient(s). This confidentiality is not waived or
lost, if you receive it and you are not the intended recipient(s), or if it is
transmitted/received in error.
Any unauthorised use, alteration, disclosure, distribution or review of this
email is prohibited. It may be subject to a statutory duty of confidentiality
if it relates to health service matters.
If you are not the intended recipient(s), or if you have received this email in
error, you are asked to immediately notify the sender by telephone or by return
email. You should also delete this email and destroy any hard copies produced.
***********************************************************************************
|
