ADSM-L

Filespace Collocation Flaw

1999-02-11 21:29:46
Subject: Filespace Collocation Flaw
From: Simon Watson <Simon.S.Watson AT OPENMAIL.FIC32.BSPSER.SIMIS DOT COM>
Date: Fri, 12 Feb 1999 10:29:46 +0800
We have been playing with Filespace Collocation recently and have found
a significant flaw in the logic that is used to determine what tape to
use.  This is what ADSM does with file space collocation turned on:

      it first looks for a tape that has data from the same filespace
      if not found it then looks for a new scratch tape
      if no sctach tapes, next it looks for a tape that has data from the
same node (and a tape that is already mounted will be first choice)

Potentially this means if you have 10 file spaces to go to a collocated
tape pool with only 5 tapes, the first 5 file spaces will be fine, they
will all go to new & separate scratch tapes, but then the last 5
filespaces will all go to the same tape, and this data will not get
distributed accross the tapes.

The implication is for restores, in that you can not make effective use
of multiple concurrent restores because more than half the data will
all be on one tape.  It would make much more sense to choose a tape
which has the least number of file spaces already on it.  In this way
the filespaces would get distributed across the tapes so there will be
less contention when it comes to restoring the data.  Maybe it would be
even better if the new filespace went to a tape from another node!  To
maximise restore speeds it is best to spread the data onto different
tapes so there will be less contention at restore time.

Yes I realise you are better off to have enough tapes so there is only
1 file space per tape as this will maximise the restore speed, but this
is not always practical as we have a large number of small file systems
(which only take up a small proportion of a tape), mostly for
performance reasons, and want to use multiple concurrent restores for
backup, but don't want to dedicate a single (expensive) tape (& slot in
the 3494) for each individual file space.

Anybody else have any thoughts on this.  I realise it is all a question
of how much are you willing to pay for performance, but a slight
redesign in the logic would enable us to use less tapes with only a
minimal impact on performance.

Cheers,
Simon
<Prev in Thread] Current Thread [Next in Thread>