ADSM-L

Re: Collocation issues

1995-03-17 03:50:23
Subject: Re: Collocation issues
From: "Keith A. Crabb" <KEITH AT UHUPVM1.UH DOT EDU>
Date: Fri, 17 Mar 1995 02:50:23 CST
On Thu, 16 Mar 1995 19:47:13 EST Paul Zarnowski said:
>We never ran without collocation, so I don't know what the change will be
>for you.  However, I have a suggestion that I think makes sense.  We use
>it, but I've never done a careful analysis or gotten any feedback from
>IBM on whether it makes sense or not.  The suggestion is to make sure
>you don't set your LOW migration threshold too low when you turn
>collocation on.  If you do, I think this will cause increasingly extra
>tape mounts.  The lower you set LOW, the more tape mounts you will get
>(not linearly more, but exponentially more).  The reason for this, (this
>is my theory) is that when a migration process runs, ADSM selects
>filespaces which have large amounts of data on the disk storage pool
>first.  As the migration process proceeds, smaller filespaces are
>selected for migration.  Each filespace could potentially be migrated
>to a different tape, and therefore require a tape mount.  By keeping
>the LOW threshold high (we use 30%), you avoid migrating all those
>smaller filespaces.

That's pretty much the impression I get from reading the manual.  What
it would amount to is instead of mounting just enough raw tapes to get
the data from disk to tape to mounting each tape required for each
nodes filespace.  So the number of requested tape mounts would go up
based upon the number of nodes per tape.  With a few hundred clients
you'd probably see a noticable increase in tape mounts but, that would
depend highly upon the amount of disk cache you provide and how much
data you dump per migration to tape.

I've been putting serious thoughts into going to collation after we
lost a partition on one of our Unix machines and the restore operation
restored ~400M of data, 35,000 files and took a little over 15.5 hours
to complete, while having to mount some 30+ tapes.  That was a major
bummer, even the simple time savings of only having to mount 5 tapes
instead of 30+ could have shaved close to an hour off the recovery time.

>I don't see why you will need an extra tape for each node.  What
>documentation are you referring to?  Even with collocation, data from
>multiple nodes may be placed on the same tape.  Collocation tries to reduce
>the number of tapes that a node has data on when migrating data or
>reclaiming tapes.  It does so by selecting tapes which already have some
>data from that node on them.  If you want to reduce the number of tapes
>that a node has data on to a minimum, THEN you will want to allocate
>additional tapes.  The more tapes that are available, the fewer nodes there
>will be on each tape.  But it's not required to have more tapes.

I don't use scratch tapes, I define all the tapes in my tape pools.  What
I can't seem to figure out is what happens if I have collation set on for
a tape pool and then define additional tapes to that pool.  Is the server
immediately going to start up migration processes to move data from tapes
that have more than one node on them to the new empty tapes, in a effort
to achieve maximum collation? or is it going to operate strictly off the
reclamation thresold set for the tape pool?

---
Keith A. Crabb         Keith AT UH DOT EDU
Keith A. Crabb         Keith AT UH DOT EDU
University of Houston  Operating Systems Specialist +1-713-743-1530
<Prev in Thread] Current Thread [Next in Thread>