On Tue, Feb 17, 2009 at 11:33:12PM -0500, Dustin J. Mitchell wrote:
> On Tue, Feb 17, 2009 at 11:06 PM, stan <stanb AT panix DOT com> wrote:
> OK, a few pieces of Amanda history may be relevant to your investigations
> here.
>
> First, Amanda no longer assumes it is using a tape drive (that is,
> something which 'mt' might be able to operate). This is a part of the
> Device API which was introduced in 2.6.0. The only point at which
> changer scripts need to interact with a device is to determine whether
> it's ready or not -- in chg-zd-mtx and chg-manual. For this, these
> scripts now use amdevcheck. This has brought its own set of issues,
> but is fully functional and does not involve 'mt' in any way.
>
> Second, there are a number of other changes to the changer API in
> 2.6.1 -- see amanda-changers(7) and
> http://wiki.zmanda.com/index.php/Changer_API for a taste. Among lots
> of other interesting action, we're deprecating and removing all of the
> old shell scripts. At the moment, the new Changer API is *always*
> used, via a C-to-perl (and old-to-new) wrapper script
> (changer-src/chg-glue.pl[1]) and a perl-to-shell (and new-to-old)
> wrapper script (perl/Amanda/Changer/compat.pm). There's room for
> problems at several points along this chain. I'm busily at work
> rewriting changers into the new API, and rewriting the Amanda taper in
> Perl so that it can utilize the new API directly. You can see the new
> Amanda::Changer::rait at
> http://github.com/djmitche/amanda/tree/chg-rait-pl/perl/Amanda/Changer/rait.pm
> (and, if you're willing to build Amanda from source, you may be able
> to use this to fix your chg-multi problems).
>
> I woul suggest looking into the source of chg-multi to see where it
> puts its debugging information, and potentially adding more debugging
> echo's as necessary to see what it's doing. Also look at the taper
> debug log to see what commands it's sending to the changer. You may
> be able to run simpler operations using 'amtape', rather than running
> an entire amdump just to replicate the failure.
>
> Good luck, happy hunting, and, if you've got some Perl-fu, please
> consider coding up a new-style Amanda::Changer::multi!
>
So, it appears as though we have broken existing functionality, at some
point in these changes. Let em describe what we have that is working, but
no longer works, and perhaps you can enlighten me as to how this
configuration _should_ work in the new system.
We have a RAIT. It consists of 25 vtapes, on one side, and an LTO
tape drive (not a changer) on the other side. Actually we have 3
configurations, the RAIT is used for backups, and we have 2 other
configurations for restore. One of them uses the vtape side of the RAIT, and
the other uses the tapes. The idea is that the first recourse for restoring
would be from the vtape, because it is faster, but we can fall back to
tape, if necessary. We would never attempt a restore from the RAIT for
obvious reasons.
There is a main amanda.conf, and a very few things are overridden in it by
the specific configs. For the RAIT, the overrides are as follows:
includefile "/opt/amanda/etc/amanda.conf.main"
tpchanger "chg-multi"
changerfile "/opt/amanda/etc/DailyDump/chg-multi.conf"
tapetype RAIT
tapedev "{file:/vtapes/DailyDump,tape:/dev/nst0}"
The settings in chg-multi.conf look like this:
multieject 0
gravity 0
needeject 0
ejectdelay 0
statefile /opt/amanda/etc/DailyDump/changer-status
firstslot 1
lastslot 25
slot 1 rait:{file:/vtapes/DailyDump/vtape1,tape:/dev/nst0}
slot 2 rait:{file:/vtapes/DailyDump/vtape2,tape:/dev/nst0}
slot 3 rait:{file:/vtapes/DailyDump/vtape3,tape:/dev/nst0}
slot 4 rait:{file:/vtapes/DailyDump/vtape4,tape:/dev/nst0}
slot 5 rait:{file:/vtapes/DailyDump/vtape5,tape:/dev/nst0}
slot 6 rait:{file:/vtapes/DailyDump/vtape6,tape:/dev/nst0}
slot 7 rait:{file:/vtapes/DailyDump/vtape7,tape:/dev/nst0}
slot 8 rait:{file:/vtapes/DailyDump/vtape8,tape:/dev/nst0}
slot 9 rait:{file:/vtapes/DailyDump/vtape9,tape:/dev/nst0}
slot 10 rait:{file:/vtapes/DailyDump/vtape10,tape:/dev/nst0}
slot 11 rait:{file:/vtapes/DailyDump/vtape11,tape:/dev/nst0}
slot 12 rait:{file:/vtapes/DailyDump/vtape12,tape:/dev/nst0}
slot 13 rait:{file:/vtapes/DailyDump/vtape13,tape:/dev/nst0}
slot 14 rait:{file:/vtapes/DailyDump/vtape14,tape:/dev/nst0}
slot 15 rait:{file:/vtapes/DailyDump/vtape15,tape:/dev/nst0}
slot 16 rait:{file:/vtapes/DailyDump/vtape16,tape:/dev/nst0}
slot 17 rait:{file:/vtapes/DailyDump/vtape17,tape:/dev/nst0}
slot 18 rait:{file:/vtapes/DailyDump/vtape18,tape:/dev/nst0}
slot 19 rait:{file:/vtapes/DailyDump/vtape19,tape:/dev/nst0}
slot 20 rait:{file:/vtapes/DailyDump/vtape20,tape:/dev/nst0}
slot 21 rait:{file:/vtapes/DailyDump/vtape21,tape:/dev/nst0}
slot 22 rait:{file:/vtapes/DailyDump/vtape22,tape:/dev/nst0}
slot 23 rait:{file:/vtapes/DailyDump/vtape23,tape:/dev/nst0}
slot 24 rait:{file:/vtapes/DailyDump/vtape24,tape:/dev/nst0}
slot 25 rait:{file:/vtapes/DailyDump/vtape25,tape:/dev/nst0}
slot 24 rait:{file:/vtapes/DailyDump/vtape24,tape:/dev/nst0}
slot 25 rait:{file:/vtapes/DailyDump/vtape25,tape:/dev/nst0}
Can you make any suggestions as to how to come up with a configuration for
the new system that will replicate the existing functionality.
--
One of the main causes of the fall of the roman empire was that, lacking
zero, they had no way to indicate successful termination of their C
programs.
|
