AHA-2940UW, DLT, alpha & aic driver

[David Rector]

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