Bug 15025

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

> > 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

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

> > 
> > > > 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

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

I think, after we've discussed this, that you should probably just close
it.

Comment 7 Kenneth D. Merry 1999-12-05 05:19:24 UTC

State Changed
From-To: open->closed

Closed at the request of the submitter. 

Comment 8 Kenneth D. Merry 1999-12-05 05:19:24 UTC

Responsible Changed
From-To: freebsd-bugs->ken

My driver.