AHA-2940UW, DLT, alpha & aic driver

[David Rector]

After reading you messsage again, I do recall a bug in st as well for
the RH5.1 and RH5.2 releases ...

Dave Rector
*:^)

On Wed, 1 Mar 2000, David Rector wrote:

> 
> I have several types of DLT drives connected to my AHA2940UW, no problems
> here with any of the mt commands. I am running the standard RedHat 6.1
> with updates, no other patches. 
> 
> As I explained earlier, mt was broken in RedHat 5.1 and 5.2
> 
> Out of curiosity, what happens when you do:
> 
> mt -f /dev/nst0 rewind
> mt -f /dev/nst0 tell
> mt -f /dev/nst0 fsf 1
> mt -f /dev/nst0 tell
> mt -f /dev/nst0 fsf 1
> mt -f /dev/nst0 tell
> 
> Another thing to watch out for is the block size setting. Sometimes, I
> encounter tapes that have been written with fixed block sizes. In this
> case you need to try:
> 
> mt -f /dev/nst0 setblk n
> 
> for DLT tapes, n is usually either 1024 or 10240
> 
> Dave Rector
> *:^)
> 
> On Wed, 1 Mar 2000, Metod Kozelj wrote:
> 
> > Hello,
> > 
> > On Wed, 1 Mar 2000, Doug Ledford wrote:
> > 
> > > > My problem real problem is, that 'mt -f /dev/nst0 fsf' doesn't do
> > > > anything.
> > > 
> > > In what context?  Several tape drives I've worked with in the past will accept
> > > the fsf command silently, seeming to do nothing, but if you actually tried to
> > > read or write to the tape after executing the command, then the drive does the
> > > reposition before the read or write.  In my experience, it works just fine. 
> > > Regardless though, this wouldn't be an aic7xxx driver problem, this would be a
> > > problem in the scsi tape driver (if it is even a problem).
> > 
> > Another member of this list suggested that this was a problem of mt,
> > shipped with RH5.1 and RH5.2. Upgrading to mt shipped with RH6.1 indeed
> > solved that problem.
> > 
> > Regarding your suggestion: if I do
> > 
> > mt -f /dev/nst0 fsf 1
> > tar -tvf /dev/nst0
> > 
> > it still acesses the first archive on tape. So it never actually performs
> > forward seek.
> > 
> > > > There's some funny thing about /proc/scsi/aic7xxx/0 contents: statisctics
> > > > for the DLT never change while statistics for disks do change.
> > > 
> > > The driver uses the cmd->request.cmd variable as the main indicator of whether
> > > the command is a read or a write command.  If the upper layer SCSI driver
> > > doesn't fill that variable in, then you see the behavior you are seeing. 
> > > Furthermore, we only track the transfer data on commands that actually use a
> > > command buffer, there are a number of commands, such as fsf, that don't
> > > trigger any sort of data length calculation in the driver.
> > 
> > So you are suggesting that even if I actually read the data from DLT
> > (using 'tar -tvf /dev/nst0'), it's just fine for stats not to reflect any
> > reads? And that this is st driver's failure?
> > 
> > Regards,
> >   Metod
> > 
> > Metod Kozelj
> > 
> > mailto:Metod.Kozelj at rzs-hm.si            /\  Ne posiljajte mi smeti ker grizem!
> > http://www.rzs-hm.si/                   /  \  Don't spam me for I bite!
> > _______________________________________/    \__________________________________
> > 
> > ---- perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
> > 
> > 
> > 
> > 
> > To Unsubscribe: send mail to majordomo at FreeBSD.org
> > with "unsubscribe aic7xxx" in the body of the message
> > 
> 
> 
> 
> To Unsubscribe: send mail to majordomo at FreeBSD.org
> with "unsubscribe aic7xxx" in the body of the message
> 



To Unsubscribe: send mail to majordomo at FreeBSD.org
with "unsubscribe aic7xxx" in the body of the message