Date: Sun, 21 Nov 1999 20:20:02 -0800 (PST) From: "Kenneth D. Merry" <ken@kdm.org> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/15025: chio appears to ignore ACCESS field Message-ID: <199911220420.UAA02037@freefall.freebsd.org>
index | next in thread | raw e-mail
The following reply was made to PR bin/15025; it has been noted by GNATS.
From: "Kenneth D. Merry" <ken@kdm.org>
To: mjacob@feral.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/15025: chio appears to ignore ACCESS field
Date: Sun, 21 Nov 1999 21:16:48 -0700 (MST)
Matthew Jacob wrote...
> > >
> > > > > I believe chio *should* have said: "You can't do this because the source
> > > > > element is not accessible".
> > > >
> > > > So what *did* happen? You only say what you think should have happened.
> > >
> > > It allowed the move to occur. Turns out it was 'okay'.
> >
> > So the move actually worked? There wasn't a SCSI error?
>
> Yes.
Hmm.
> > Some tape changers have the ability to eject a tape if you ask to move it
> > out of a drive and it isn't already ejected. Perhaps that's what yours
> > did?
>
> No. This was an exabyte 210. It, or camcontrol, was just plain wrong about
> the actual accessability.
camcontrol? Don't you mean chio?
My guess is that chio is just reporting what the changer told it.
> Yes, some drives have autoeject. But they also usually say that the
> DT element is accessable (see below).
Hmm, okay.
But in order for that command to work, one of the following must have been
true:
- the changer ejected the tape
- the tape was already ejected, but the changer didn't report it as
accessible
- the changer wasn't actually able to complete the move, but didn't return
any SCSI errors.
- the ch driver got a SCSI error, but didn't report it
I suspect that one of the first two reasons is probably true. Any idea
what's going on?
> > > > I think it's probably better to do state checking in the driver than in
> > > > chio, since the driver has a more persistent view of things.
> > >
> > > That I'm not convinced of as I believe the only reason scsi_ch should
> > > exist is to mediate device ownership. But maybe chio's notion of things
> > > was wrong somehow.
> >
> > I don't think the driver checks to see whether the source or destination
> > are accessible before trying to do the move. The changer will complain if
> > it doesn't like what you're trying to do.
>
> Well, yes, this is fine for small changers. It's somewhat heavy weight
> for large STK silos which may or may not eventually tell you can't do
> this, but after a 10 minute wait, etc...
Keeping track of whether things are accessible or not might take a read
element status before every move. That seems like a lot of overhead.
For instance, if you relied on cached accessibility information in the
driver to make decisions on whether or not to issue a command, you'd run
into situations where the following would not work:
mt rewoffl
chio move drive 0 slot 5
Since the ch driver would might still think that the drive was inaccessible,
you'd either have to do this:
mt rewoffl
chio status
chio move drive 0 slot 5
Or have the driver perform a read element status before every move, or
before every move that involved a drive.
> > The driver does check to make sure what you're asking for fits the device's
> > claimed capabilities, and does some bounds checking to make sure you aren't
> > asking for elements that don't exist.
> >
> > One reason I see for not putting all the smarts into chio is that you want
> > to be able to easily write another program -- like amanda -- that can use
> > the changer ioctls and have a reasonably decent software interface.
>
> Amanda? Smart? Amanda use *chio* in a perl script last I checked...
Amanda also has (had?) a module that used the ch driver's ioctl set to do
the moving. I ported it to CAM a while back.
I was never able to try the ch driver interface, for lack of a decent
changer setup to test it on.
> Here's the output of the stuff I did for Legato for a Python changer-
> as soon as a current eot_test finishes on the 210, I'll rerun it on
> the 210 as well... Note that the DT element *is* accessable.
>
> Whether the smarts are in chio or not, I believe that somebody has to
> pay attention to not only limits but the element movement matrix,
> the access bits, etc.
I think that's possible, but best done in the driver if anywhere. See my
comments above about what this might mean in terms of overhead.
> For example, I would warn folks *strenously* against using any of the two
> drive ADIC/VLS units. The ADIC/VLS changers are simple- a fixed
> pusher/grabber arm that push or pull a cartridge, and a cartridge box
> that moves back and forth to put a cartridge within reach. The only way to
> have two drives is that the drives are behind an open portal themselves on
> a moving tray- and the ACCESS value tells you which one can be pushed to
> or ejected from, and you're in deep doodoo (i.e. "Break your 10K$
> changer") if you ignore this ACCESS value.
Yuck. I suppose I shouldn't be surprised that some changer vendors can't
seem to design decent products. I suppose the general attitude is that
standards are made to be broken, 'eh?
> bird > root /etc/LGTOuscsi/changers -v -a 0.4.1
> scsidev@0.4.1:Vendor <ARCHIVE>, Product <Python 28849-XXX>, Revision <4.>
>
> 1 MT Element(s) starting at address 0
> 4 ST Element(s) starting at address 2
> 1 DT Element(s) starting at address 1
>
> Element Movement Matrix
>
> ->DT,______, ->ST,______
> ______,______,______,______
> ST->DT,______,______,______
> ______,______,______,______
> ______,______,DT->ST,______
> ______,______,______,______
> ST<>DT,______,______,______
> ______,______,______,______
> ______,______,______,______
Maybe I'm dense, but I don't quite understand what that matrix represents..
Ken
--
Kenneth Merry
ken@kdm.org
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
home |
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911220420.UAA02037>