ADSM-L

Re: Using FILE instead of DISK devclass to avoid disk under-utilization

2006-10-25 18:01:16
Subject: Re: Using FILE instead of DISK devclass to avoid disk under-utilization
From: Daniel Clark <dclark AT POBOX DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 25 Oct 2006 17:44:52 -0400
On 10/25/06, Prather, Wanda <Wanda.Prather AT jhuapl DOT edu> wrote:
Um.  I don't really see what the issue is.

TSM is elegantly designed to automatically compensate for a disk pool
being too small on occasion by kicking in the migration to tape
automatically for you, based on the thresholds you set.
So it's working as designed.

In the TSM "circle of life" you generally do not want to have disk
pools being migrated to tape at the same time clients are backup up
data to the disk pool - disk is usually the bottleneck for any TSM
operation, so this can half disk performance, and force client backup
out of the nightly backup window, into production hours.

We also have some clients with really large numbers of large files, as
well as NDMP clients, that we just have go directly to tape (not
optional in the NDMP case); if migration is happening, the number of
tape mount points can be decreased to the point that these clients
block, again causing backup windows to be missed.

I think you may be working too hard to fix something that isn't broken?

It's just not the most effective use of disk, which by definition is
random access and so does not benefit by being preallocated to a
certain use. IMHO from a sys admin perspective it would make more
sense to just have DISK devclass not be associated with any specific
storage pool, but rather have it be a shared resource amongst all
storage pools, and just have data that is fed into it be tagged in the
TSM DB as belonging to a certain storage pool, so it goes to the right
set of tapes or other external media. Perhaps from a dev perspective
there is a good reason not to do that, but that would require someone
in IBM development to respond.

Why do you consider the migration to be a problem, if your data is going
to end up on tape eventually anyway?

Because I do not want migration happening at the same time as client
backups, for the above-stated reasons. It's a matter of timing and
performance, not eventual location.