ADSM-L

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

2006-10-25 18:10:36
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:54:00 -0400
On 10/25/06, Thomas Denier <Thomas.Denier AT jeffersonhospital DOT org> wrote:
We are using this kind of setup with TSM 5.2. We have run into two
types of problems.

The first problem is that things get really ugly if the storage
pools collectively get larger than the shared disk space.

Ugly in what kind of way? Clients don't just block until one of the
FILE class devices on disk is migrated to a tape storage pool, and
thus reset to scratch?

The second problem is that file volumes are treated like tapes in
many respects. In particular, only one session or process can have
a particular file volume open at a given time. We occasionally have
a client session that slows to a crawl, keeping a file volume open
for hours. This can cause backup stgpool and migration processes
to hang when they want to read the volume involved.

I was thinking of creating a decently large number of FILE devclass
devices on disk - say 100GB each over 4TB = 40 devices. I would think
the chances of all of them being locked by hanging clients would be
pretty small.

I am hoping to get rid of this setup once we upgrade to TSM 5.3.
I think we will be able to use a single storage pool hierarchy,with
collocation groups used to control sharing of tapes.

That works well for many cases, and is in fact what we already do in
some places; however there are cases where that can't do what you want
to do. For example for DR testing we need to have a small set of
machines where there are 2 copy pools for the primary storage pool, so
we can pull tapes from offsite for regulation-required monthly checks
without creating a DR hole (i.e. media is onsite, there is a disaster,
we are screwed).

--
Daniel Joseph Barnhart Clark
http://www.pobox.com/users/dclark