From owner-freebsd-bugs Sun Nov 21 16: 0:12 1999 Delivered-To: freebsd-bugs@freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (Postfix) with ESMTP id 1AC86152C0 for ; Sun, 21 Nov 1999 16:00:02 -0800 (PST) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.9.3/8.9.2) id QAA47115; Sun, 21 Nov 1999 16:00:02 -0800 (PST) (envelope-from gnats@FreeBSD.org) Date: Sun, 21 Nov 1999 16:00:02 -0800 (PST) Message-Id: <199911220000.QAA47115@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org Cc: From: Matthew Jacob Subject: Re: bin/15025: chio appears to ignore ACCESS field Reply-To: Matthew Jacob Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The following reply was made to PR bin/15025; it has been noted by GNATS. From: Matthew Jacob To: "Kenneth D. Merry" 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 , Product , 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