It might be just a phylosofical point of view. But you can look at the
collocation in this strict order:

        1 - Filespace Collocation
        2 - Node collocation
        3 - No collocation

Logically if you cannot have a "Filespace Collocation" for whatever
reasons, you degrade towards "Node Collocation", if you cannot have "Node
Collocation" ... and this seems to be how ADSM works.
How you achieve it is a matter of choice!

Yours

Ciao Mauro


> 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
>