From mjacob@feral.com Sun Nov 21 11:25:07 1999
Return-Path: <mjacob@feral.com>
Received: from feral.com (feral.com [192.67.166.1])
	by hub.freebsd.org (Postfix) with ESMTP id D61EA1590F
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 21 Nov 1999 11:24:33 -0800 (PST)
	(envelope-from mjacob@feral.com)
Received: from frobzit.feral.com (frobzit [192.67.166.157])
	by feral.com (8.8.7/8.8.7) with ESMTP id LAA00639
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 21 Nov 1999 11:25:15 -0800
Received: (from mjacob@localhost)
	by frobzit.feral.com (8.9.3/8.9.3) id LAA00803;
	Sun, 21 Nov 1999 11:25:15 -0800 (PST)
	(envelope-from mjacob@feral.com)
Message-Id: <199911211925.LAA00803@frobzit.feral.com>
Date: Sun, 21 Nov 1999 11:25:15 -0800 (PST)
From: Matthew Jacob <mjacob@feral.com>
Reply-To: mjacob@feral.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: chio appears to ignore ACCESS field
X-Send-Pr-Version: 3.2

>Number:         15025
>Category:       bin
>Synopsis:       chio appears to ignore ACCESS field
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    ken
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Nov 21 11:30:01 PST 1999
>Closed-Date:    Sat Dec 4 21:19:24 PST 1999
>Last-Modified:  Sat Dec  4 21:20:41 PST 1999
>Originator:     Matthew Jacob
>Release:        FreeBSD 4.0-CURRENT i386
>Organization:
Feral Software
>Environment:

FreeBSD frobzit.feral.com 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Sun Nov 21 11:06:48 PST 1999     mjacob@quarm.feral.com:/freebsd/FreeBSD-current/sys/compile/FROBZIT  i386

>Description:

Did a chio status on an Exabyte 210:

frobzit.feral.com > chio status
picker 0: 
slot 0: <ACCESS>
slot 1: <ACCESS,EXCEPT,FULL>
slot 2: <ACCESS,EXCEPT,FULL>
slot 3: <ACCESS,EXCEPT,FULL>
slot 4: <ACCESS,EXCEPT,FULL>
slot 5: <ACCESS,EXCEPT,FULL>
slot 6: <ACCESS>
slot 7: <ACCESS>
slot 8: <ACCESS>
slot 9: <ACCESS>
slot 10: <ACCESS>
drive 0: 
drive 1: <EXCEPT,FULL>

immediately followed by a move:

frobzit.feral.com > chio move drive 1 slot 0

I believe chio *should* have said: "You can't do this because the source
element is not accessible".

>How-To-Repeat:

see above

>Fix:



>Release-Note:
>Audit-Trail:

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 16:17:49 -0700 (MST)

 Matthew Jacob wrote...
 > FreeBSD frobzit.feral.com 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Sun Nov 21 11:06:48 PST 1999     mjacob@quarm.feral.com:/freebsd/FreeBSD-current/sys/compile/FROBZIT  i386
 > 
 > >Description:
 > 
 > Did a chio status on an Exabyte 210:
 > 
 > frobzit.feral.com > chio status
 > picker 0: 
 > slot 0: <ACCESS>
 > slot 1: <ACCESS,EXCEPT,FULL>
 > slot 2: <ACCESS,EXCEPT,FULL>
 > slot 3: <ACCESS,EXCEPT,FULL>
 > slot 4: <ACCESS,EXCEPT,FULL>
 > slot 5: <ACCESS,EXCEPT,FULL>
 > slot 6: <ACCESS>
 > slot 7: <ACCESS>
 > slot 8: <ACCESS>
 > slot 9: <ACCESS>
 > slot 10: <ACCESS>
 > drive 0: 
 > drive 1: <EXCEPT,FULL>
 > 
 > immediately followed by a move:
 > 
 > frobzit.feral.com > chio move drive 1 slot 0
 > 
 > 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.
 
 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.
 
 Ken
 -- 
 Kenneth Merry
 ken@kdm.org
 

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:28:28 -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'. 
 
 
 > 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.
 
 -matt
 
 
 
 
 

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 16:37:59 -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?
 
 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?
 
 > > 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.
 
 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.
 
 Ken
 -- 
 Kenneth Merry
 ken@kdm.org
 

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
 
 
 

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
 

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: Sat, 4 Dec 1999 10:14:36 -0800 (PST)

 I think, after we've discussed this, that you should probably just close
 it.
 
 
 
 
State-Changed-From-To: open->closed 
State-Changed-By: ken 
State-Changed-When: Sat Dec 4 21:19:24 PST 1999 
State-Changed-Why:  
Closed at the request of the submitter. 


Responsible-Changed-From-To: freebsd-bugs->ken 
Responsible-Changed-By: ken 
Responsible-Changed-When: Sat Dec 4 21:19:24 PST 1999 
Responsible-Changed-Why:  
My driver. 
>Unformatted:
