ADSM-L

Re: one stgpool migrates to two?

1998-03-19 17:17:49
Subject: Re: one stgpool migrates to two?
From: Doug Thorneycroft <dthorneycroft AT LACSD DOT ORG>
Date: Thu, 19 Mar 1998 14:17:49 -0800
Would Co-locating the storage pool work, this would place each node
onto a separate tape, although all tapes would belong to the same
tapepool.

Thomas A. La Porte wrote:
>
> Jerry,
>
> You're right, there doesn't seem to be a way to do what I'd like.
> I'll admit to a certain amount of laziness on my part for this
> question. Basically we have a small disk pool (ca 30GB), and
> several different projects whose data should be kept in separate
> tape pools. On any given night, the disk pool is enough to
> cover the entire backup for all projects. The problem is, if
> I have to split the disk pool into separate project-based
> disk pools, there are bound to be many nights when one
> project overflows its disk pool, prompting a migration that I
> don't want to have happening during the backup window.
> Meanwhile, I might have plenty of disk space from one of the
> other projects. What I'd really like to have is a single disk
> pool, so that I don't have to determine which projects are
> backing up more or less data this week.
>
> Maybe a v3rN feature (where N is an element of the set of real
> integers)?
>
> "It's a dog eat dog world,                Thomas A. La Porte
>  and I'm wearing milkbone underwear."     DreamWorks SKG
>               - Norm Peterson             <tlaporte AT anim.dreamworks DOT 
> com>
>
> On Thu, 19 Mar 1998, Jerry Lawson wrote:
>
> >---------------------------- Forwarded with Changes 
> >---------------------------
> >From: INTERNET.OWNERAD at SNADGATE
> >Date: 3/18/98 1:21PM
> >To: Jerry Lawson at ASUPO
> >*To: *ADSM-L at SNADGATE
> >Subject: one stgpool migrates to two?
> >-------------------------------------------------------------------------------
> >Thomas.
> >
> >As a general case, I'd say the answer to your question is "No".
> >
> >It is certainly possible to have multiple copygroups going to the same pool -
> >just point him to the pool of your choice.  But the migration from that pool 
> >to
> >the next is controlled by the first pool.  The only "exception" to that 
> >process
> >that I can think of is if there was a size limit on that pool, causing files
> >over a certain size to go to another pool.  But that doesn't sound like what 
> >you
> >want - it would be indiscriminate with regards to where the files came from -
> >only how big they are.
> >
> >Jerry Lawson
> >jlawson AT thehartford DOT com
> >
<Prev in Thread] Current Thread [Next in Thread>