[1830] in linux-scsi channel archive
Re: Incorrect block number returned by MTIOCGET?
daemon@ATHENA.MIT.EDU (Kai M{kisara)
Thu May 8 11:56:14 1997
Date: Thu, 8 May 1997 18:55:06 +0300 (EET DST)
From: Kai M{kisara <makisara@abies.metla.fi>
Reply-To: Kai.Makisara@metla.fi
To: Jan Echternach <jan.echternach@informatik.uni-rostock.de>
cc: linux-scsi@vger.rutgers.edu
In-Reply-To: <19970507141405.16368@zirkon.informatik.uni-rostock.de>
On Wed, 7 May 1997, Jan Echternach wrote:
> Hi,
>
> When I was tracking down a problem with taper (seeking didn't work
> somehow), I found out that MTIOCGET can return a block number that
> seems incorrect to me:
>
...
> 3. seek to filemark
> 4. close
> 5. open rewinding device
> 6. MTIOCPOS -> block 12
> 7. MTIOCGET -> block 0 (Is this correct?)
If you look at the file number, you should see file 1. MTIOCPOS counts
blocks from the beginning of the tape whereas MTIOCGET counts from the
beginning of the file. This is documented both in the st man page and in
linux/drivers/scsi/README.st.
>
>
> Now something different: When I was browsing through st.c, I found
> this code:
>
> > scsi_tape_open():
> > if ((STp->buffer)->last_result_fatal != 0) {
> > if ((SCpnt->sense_buffer[0] & 0x70) == 0x70 &&
> > (SCpnt->sense_buffer[2] & 0x0f) == NO_TAPE) {
> > (STp->mt_status)->mt_fileno = STp->drv_block = 0 ;
> > STp->ready = ST_NO_TAPE;
> > } else {
> > (STp->mt_status)->mt_fileno = STp->drv_block = (-1);
> > STp->ready = ST_NOT_READY;
> > }
...
> > (STp->mt_status)->mt_fileno = STp->drv_block = 0;
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
As you suspect, this seems to be a bug. It is harmless because it only
affects the file and block numbers in MTIOCGET in a situation when you
can't do anything with the tape. When you correct the problem, you must
reopen the tape anyway and then the file and block numbers are set to
correct values.
Kai
