--On Tuesday, September 24, 2002 17:43:47 -0700 Alan Horn <ahorn AT inktomi DOT 
com> wrote:

> 
> 
> If one has a robot library with multiple drives, it's my understanding
> that amanda has to have a separate configuration for each of those
> drives. In other words, you can't run a backup and use all drives against
> one disklist.
> 
> Correct me if I'm wrong there, if I _am_ wrong it'll make my life so much
> easier :)
 
I think the beta version will let you configure your drives as a RAIT
(like a disk RAID but using tape drives), which should vastly increase
your write speeds at the expense of quite a bit of complexity (like
loading 6 tapes at a time to do a restore).

> Now, how do people handle contention for use of the robot ?
> 
> If I have 6 drives, and therefore 6 configs (call them tape1 thru tape6
> for simplicity), and a 238 slot jukebox with a robot changer. I divide up
> the slots, 39 per drive (approx), and then have each chunk of 39 slots be
> a separate stack as it were.
> 
> However, as I've seen, when labelling (and I'm sure less commonly, but the
> condition will also exist when taping). Two amanda processes can reach for
> the robot at the same time,since in this configuration they have no
> knowledge of other processes.
> 
> This results in errors like :
> 
> amlabel: could not load slot "current": open SCSI device '/dev/changer' -
> Device busy
> etc...
> 
> Is this something that needs to be dealt with by the underlying mtx
> changer code, or have I miconfigured amanda and it can be done more
> effiiciently ?
> 
> So far, I love amanda, it's very promising. But until I solve this changer
> problem, I can't really deploy it.

Amanda seems to be really lacking (to me) in its capabilities for
simultaneous configs, both in its client-server communications and
its handling of multiple drives and changers.
  You could put a wrapper around the changer script that would
use a lock file to control accesses to the changer, where the wrapper
would just sleep if the lock existed and retry a little later. Or it
may be easier to build it into the existing changer scripts.  
Hopefully there are no internal timeouts in Amanda on the changer calls.
  Maybe I'm wrong too.  I had troubles setting up a second config
for offsites and finally just settled for staggering the runs so
that the runs don't overlap.  As the backup requirements grow, this
will become more and more difficult to achieve.  Perhaps this feature
(concurrent runs) is in the new betas.

Frank

> 
> Cheers,
> 
> Al
> 
> 
> --
>                                  Alan C. Horn
>                            Inktomi - Unix Architect.
>                                +1-650-653-5436
>                               [ahorn AT inktomi DOT com]



--
Frank Smith                                                fsmith AT hoovers 
DOT com
Systems Administrator                                     Voice: 512-374-4673
Hoover's Online                                             Fax: 512-374-4501