Date: Wed, 1 Mar 2000 07:46:26 -0700 (MST) From: David Rector <dave@clean.lanl.gov> To: Metod Kozelj <metod.kozelj@rzs-hm.si> Cc: Doug Ledford <dledford@redhat.com>, aic7xxx@FreeBSD.ORG Subject: Re: AHA-2940UW, DLT, alpha & aic driver Message-ID: <Pine.LNX.4.10.10003010740030.1413-100000@clean.lanl.gov> In-Reply-To: <Pine.HPP.3.96.1000301074426.27969B-100000@hmljhp.rzs-hm.si>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@FreeBSD.org > with "unsubscribe aic7xxx" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe aic7xxx" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.10.10003010740030.1413-100000>