Date: Tue, 23 Mar 1999 10:54:58 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: Charles Owens <owensc@enc.edu> Cc: cwt@FreeBSD.ORG, kingsled@enc.edu, nick.hibma@jrc.it, freebsd-scsi@FreeBSD.ORG, Brian Topping <topping@digidemic.com> Subject: Re: fix for amanda chg-chio script to eject tape Message-ID: <Pine.LNX.4.04.9903231046450.24188-100000@feral-gw> In-Reply-To: <36F6990E.1E5026DD@enc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
Sorry for the delay. I'm still ill with this cold ("I feel like a military
school. Parts of me keep passing in and out").
> > What did the code in amanda used to be?
>
> Below is the Unload subroutine from the chg-chio script (Perl). I inserted my
> commands to eject the tape just before the 'if' statement.
Okay.
> > At any rate, the 3.X SA driver does a PREVENT at open time, and an ALLOW
> > at close- pretty much unconditionally.
> >
> > Some changers allow you to eject the tape whether the drive has it
> > prevented or not, so which changers are you referring to?
> >
>
> Wow... is the SA driver okay with a changer dong this? I'd made an assumption that
> this wasn't cool. Okay... then the chg-chio code as is makes sense for this sort
> of changer... but not mine.
Some changers have extra wires going into the drive to force the eject.
The LAGO datawheel (an ancient changer) comes to mind. So does the
(Archive/Connor/Seagate) Python DAT changer.
The SCSI changer model is a bit passive in this area- you get bits for an
element that tell you whether the element is 'accessable'- but it's left
to implementation or device as to *how* to make the element accessable
when it isn't. How you can map this to usage of perl wrapped around chio I
dunno- grep for ACCES I guess?
> The system I'm using is a 28-tape changer from a company called MediaLogic. It has
> a Sony AIT-1 drive (which, since sa(4) doesn't know the AIT extended features, is
> being treated like just a big 8mm drive).
(send me a manual and do some testing for me and the 'advanced' features
may become available- *I* don't have 10-20K$ to buy one....)
>
> Once a tape is inserted into the drive it is completely beyond the reach of the
> changer. When the tape is ejected by the OS, it hangs out in this intermediate
> space from which the changer may come by and grab it.
That's what I mean. You have to make it 'accessable'. I believe that
amanda must not have worked with this kind of changer before. You'd get
the same effect with an Exabyte 210.
*Or* you need to use the 'eject on close' tape device for FreeBSD- that
will save you from having to issue the 'mt offl'- but I don't know whether
you are trying to use multiple tape files or not on a tape - that could be
a problem, yup...
>
> >
> > Also, an 'offline' does a 'rewind' too, so you only have to do one- but
> > now that I think about it- *this* particular bit of additional code can
> > cause you some problems for the changers that may be (incorrectly)
> > strapped to then sequentially load the next cardtridge.
> >
> > So- could you give a couple more details as to what h/w you're working
> > with, and maybe use a CAMDEBUG kernel and do a camcontrol -Ic on the tape
> > and/or changer device to see why you needed to get the tape ejected?
>
> Is what I've told you above good for now? Let me know if you need more and I'll do
> this camcontrol thing (but it'll take me a bit).
>
I'm still not sure whether there's a bug in either chio or sa. Surprise
surprise- I don't think so in this case.
-matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.04.9903231046450.24188-100000>