Date: Sun, 21 Nov 1999 16:00:02 -0800 (PST) From: Matthew Jacob <mjacob@feral.com> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/15025: chio appears to ignore ACCESS field Message-ID: <199911220000.QAA47115@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/15025; it has been noted by GNATS.
From: Matthew Jacob <mjacob@feral.com>
To: "Kenneth D. Merry" <ken@kdm.org>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: bin/15025: chio appears to ignore ACCESS field
Date: Sun, 21 Nov 1999 15:56:50 -0800 (PST)
> >
> > > > 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.
>
> 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.
Yes, some drives have autoeject. But they also usually say that the
DT element is accessable (see below).
>
> > > 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...
>
> 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...
-matt
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.
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.
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,______,______,______
______,______,______,______
______,______,______,______
bird > root /etc/LGTOuscsi/relem -v -a 0.4.1
Element Data for scsidev@0.4.1, fetched per element:
MT element range: 0..0 ST element range: 2..5
DT element range: 1..1
First Element Address: 0 Number of Elements 1
Medium Transport Element Descriptor at Address 0
InEnab=0 ExEnab=0 Access=0 Except=0 ImpExp=0 Full=0
SValid=0 Invert=0 Source_addr=0
First Element Address: 2 Number of Elements 1
Storage Element Descriptor at Address 2
InEnab=0 ExEnab=0 Access=1 Except=0 ImpExp=0 Full=1
SValid=0 Invert=0 Source_addr=0
First Element Address: 3 Number of Elements 1
Storage Element Descriptor at Address 3
InEnab=0 ExEnab=0 Access=1 Except=0 ImpExp=0 Full=0
SValid=0 Invert=0 Source_addr=0
First Element Address: 4 Number of Elements 1
Storage Element Descriptor at Address 4
InEnab=0 ExEnab=0 Access=1 Except=0 ImpExp=0 Full=1
SValid=0 Invert=0 Source_addr=0
First Element Address: 5 Number of Elements 1
Storage Element Descriptor at Address 5
InEnab=0 ExEnab=0 Access=1 Except=0 ImpExp=0 Full=1
SValid=0 Invert=0 Source_addr=0
First Element Address: 1 Number of Elements 1
Data Transfer Element Descriptor at Address 1
InEnab=0 ExEnab=0 Access=1 Except=0 ImpExp=0 Full=1
NotBus=0 IDvalid=1 LUValid=0 Lun=0 Addr=4
SValid=1 Invert=0 Source_addr=3
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199911220000.QAA47115>