Re: (fwd) Bug#11922: I/O error on blank tapes

Re: (fwd) Bug#11922: I/O error on blank tapes

[James Bottomley]

On Mon, 2008-02-04 at 22:28 +0100, Borislav Petkov wrote:
> On Mon, Feb 04, 2008 at 03:22:06PM +0100, maximilian attems wrote:
> 
> (Added Bart to CC)
> 
> > hello borislav,
> > 
> > may i forward you that *old* Debian kernel bug,
> > have seen you working on ide-tape:
> > http://bugs.debian.org/11922
> > no we don't carry any ide patches anymore.
> > 
> > maybe you've already fixed it in latest?
> > 
> > thanks
> > 
> > -- 
> > maks
> > 
> > ----- Forwarded message from Stephen Kitt <steve@sk2.org> -----
> > 
> > Subject: Bug#11922: I/O error on blank tapes
> > Date: Sat, 1 Dec 2007 19:06:18 +0100
> > From: Stephen Kitt <steve@sk2.org>
> > To: 11922@bugs.debian.org
> > 
> > Hi,
> > 
> > This does still occur with 2.6.22; with a blank tape in my HP DDS-4 drive:
> > 
> > $ tar tzvf /dev/nst0
> > tar: /dev/nst0: Cannot read: Input/output error

That's a SCSI tape, not an IDE one.  I cc'd the SCSI list

James

> > tar: At beginning of tape, quitting now
> > tar: Error is not recoverable: exiting now
> > 
> > gzip: stdin: unexpected end of file
> > tar: Child returned status 2
> > tar: Error exit delayed from previous errors
> > 
> > Nothing gets logged anywhere, which fits the original bug description.
> > 
> > This is a well-known issue: see for example
> > http://www.sibbald.com/bacula/html-manual/Bacula_Console.html (search for
> > "blank tape").
> > 
> > Regards,
> > 
> > Stephen
> > 
> > 
> > 
> > -- 
> > To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
> > with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
> > 
> > 
> > ----- End forwarded message -----
> 
> Hi Maks,
> 
> we're currently in the process of aggressively cleaning up ide-tape. However,
> this brings (almost) no functional changes to the driver and we haven't looked
> at any bugs that might exist. Actually, I wanted to probe the community to see
> whether anyone is using ide-tape at all, and if not, to remove it completely.
> 
> Since i don't have the hardware, i'm gonna have to ask you (or Stephen) to wait
> until all changes have entered mainline and then to try to reproduce the bug again
> after having enabled debugging (IDETAPE_DEBUG_LOG) and send me the syslog
> output.
> 
> Thanks.
> 

Re: (fwd) Bug#11922: I/O error on blank tapes

[Kai Makisara]

On Mon, 4 Feb 2008, James Bottomley wrote:

> 
> On Mon, 2008-02-04 at 22:28 +0100, Borislav Petkov wrote:
> > On Mon, Feb 04, 2008 at 03:22:06PM +0100, maximilian attems wrote:
> > 
> > (Added Bart to CC)
> > 
> > > hello borislav,
> > > 
> > > may i forward you that *old* Debian kernel bug,
> > > have seen you working on ide-tape:
> > > http://bugs.debian.org/11922
> > > no we don't carry any ide patches anymore.
> > > 
> > > maybe you've already fixed it in latest?
> > > 
> > > thanks
> > > 
> > > -- 
> > > maks
> > > 
> > > ----- Forwarded message from Stephen Kitt <steve@sk2.org> -----
> > > 
> > > Subject: Bug#11922: I/O error on blank tapes
> > > Date: Sat, 1 Dec 2007 19:06:18 +0100
> > > From: Stephen Kitt <steve@sk2.org>
> > > To: 11922@bugs.debian.org
> > > 
> > > Hi,
> > > 
> > > This does still occur with 2.6.22; with a blank tape in my HP DDS-4 drive:
> > > 
> > > $ tar tzvf /dev/nst0
> > > tar: /dev/nst0: Cannot read: Input/output error
> 
> That's a SCSI tape, not an IDE one.  I cc'd the SCSI list
> 
This is not a bug, it is a feature. There is _nothing_ on the tape and if 
you try to read something, you get an error. The same thing applies to 
reading after the last filemark. Note that after writing a filemark at the 
beginning of the tape, the situation is different. Now there is a file and 
the normal EOF semantics apply although there still is no data.

I admit that the error return could be more descriptive but the st driver 
tries to be compatible with other Unices.

The behavior can be changed if Linux does not match other Unices. I don't 
remember if I have tested just this with other Unices. I will try to test 
this with Tru64 tomorrow. If anyone has data on other Unices, it would be 
helpful.

-- 
Kai

Re: (fwd) Bug#11922: I/O error on blank tapes

[Kai Makisara]

On Tue, 5 Feb 2008, Kai Makisara wrote:

> On Mon, 4 Feb 2008, James Bottomley wrote:
> 
> > 
> > On Mon, 2008-02-04 at 22:28 +0100, Borislav Petkov wrote:
> > > On Mon, Feb 04, 2008 at 03:22:06PM +0100, maximilian attems wrote:
> > > 
> > > (Added Bart to CC)
> > > 
> > > > hello borislav,
> > > > 
...
> > > > This does still occur with 2.6.22; with a blank tape in my HP DDS-4 drive:
> > > > 
> > > > $ tar tzvf /dev/nst0
> > > > tar: /dev/nst0: Cannot read: Input/output error
> > 
> > That's a SCSI tape, not an IDE one.  I cc'd the SCSI list
> > 
> This is not a bug, it is a feature. There is _nothing_ on the tape and if 
> you try to read something, you get an error. The same thing applies to 
> reading after the last filemark. Note that after writing a filemark at the 
> beginning of the tape, the situation is different. Now there is a file and 
> the normal EOF semantics apply although there still is no data.
> 
> I admit that the error return could be more descriptive but the st driver 
> tries to be compatible with other Unices.
> 
> The behavior can be changed if Linux does not match other Unices. I don't 
> remember if I have tested just this with other Unices. I will try to test 
> this with Tru64 tomorrow. If anyone has data on other Unices, it would be 
> helpful.
> 
None of our Tru64 boxes have a user-accessible tape drive any more. 
However, I have been able to test with a Solaris box. The behavior there 
matches the Linux behavior: blank tape -> i/o error when trying to read.

-- 
Kai

Re: (fwd) Bug#11922: I/O error on blank tapes

[John LLOYD]

> On Mon, 4 Feb 2008, James Bottomley wrote:
> 
> > 
> > On Mon, 2008-02-04 at 22:28 +0100, Borislav Petkov wrote:
> > > On Mon, Feb 04, 2008 at 03:22:06PM +0100, maximilian attems wrote:
> > > 
> > > (Added Bart to CC)
> > > 
> > > > hello borislav,
> > > > 
...
> > > > This does still occur with 2.6.22; with a blank tape in my HP
DDS-4 drive:
> > > > 
> > > > $ tar tzvf /dev/nst0
> > > > tar: /dev/nst0: Cannot read: Input/output error
> > 
> > That's a SCSI tape, not an IDE one.  I cc'd the SCSI list
> > 
> This is not a bug, it is a feature. There is _nothing_ on the tape and
if 
> you try to read something, you get an error. The same thing applies to

> reading after the last filemark. Note that after writing a filemark at
the 
> beginning of the tape, the situation is different. Now there is a file
and 
> the normal EOF semantics apply although there still is no data.
> 

The question then becomes -- How to detect blank tapes on a SCSI drive
without forcing an I/O error?

My own available systems do not include recent kernels, but there are at
least two behaviours:

 SLES9 SP3 contains st.c *verstr = "20040318" (plus or minus SUSE hacks)
and the following approach works:
   % mtst -f /dev/nst0 rewind
   % mtst -f /dev/nst0 eom
   % mtst -f /dev/nst0 status
 and you get both BOT and EOD status with a blank tape, and some other
combination for empty (just EOF) or data-full tapes.

 SLES10 SP1 contains st.c *verstr = "20050830" and that method does not
work.  You just get EOD and there is no way to tell what kind of tape it
is.

Why do we care?  Because our software has to be defensive, and check the
tape before writing to it.  The tapes are fed by a robot (no trustworthy
humans involved) so checking the tape is necessary.

Now, I fully understand what list I am posting to.  The question
remains: 

How to detect blank tapes on a SCSI drive without getting an I/O error?


cheers

John

Re: (fwd) Bug#11922: I/O error on blank tapes

[Kai Makisara]

On Wed, 20 Feb 2008, John LLOYD wrote:

> 
> 
> > On Mon, 4 Feb 2008, James Bottomley wrote:
> > 
> > > 
> > > On Mon, 2008-02-04 at 22:28 +0100, Borislav Petkov wrote:
...
> > > > > This does still occur with 2.6.22; with a blank tape in my HP
> DDS-4 drive:
> > > > > 
> > > > > $ tar tzvf /dev/nst0
> > > > > tar: /dev/nst0: Cannot read: Input/output error
> > > 
> > > That's a SCSI tape, not an IDE one.  I cc'd the SCSI list
> > > 
> > This is not a bug, it is a feature. There is _nothing_ on the tape and
> if 
> > you try to read something, you get an error. The same thing applies to
> 
> > reading after the last filemark. Note that after writing a filemark at
> the 
> > beginning of the tape, the situation is different. Now there is a file
> and 
> > the normal EOF semantics apply although there still is no data.
> > 
> 
> The question then becomes -- How to detect blank tapes on a SCSI drive
> without forcing an I/O error?
> 
> My own available systems do not include recent kernels, but there are at
> least two behaviours:
> 
>  SLES9 SP3 contains st.c *verstr = "20040318" (plus or minus SUSE hacks)
> and the following approach works:
>    % mtst -f /dev/nst0 rewind
>    % mtst -f /dev/nst0 eom
>    % mtst -f /dev/nst0 status
>  and you get both BOT and EOD status with a blank tape, and some other
> combination for empty (just EOF) or data-full tapes.
> 
>  SLES10 SP1 contains st.c *verstr = "20050830" and that method does not
> work.  You just get EOD and there is no way to tell what kind of tape it
> is.
> 
The behaviour has changed because a bug has been fixed. The BOT status is 
derived from file and block number being zero. Positioning to EOD is done 
by spacing over files and this means that we don't know the number of 
blocks been spaced over. This is why the block number is invalidated 
(i.e., set to -1).

However, I think your approach can be used with small modification. Most 
(all?) current drives can tell the tape position (mt tell). If I insert a 
blank tape, with my drive I get

makisara@kai:~> mt rewi
makisara@kai:~> mt eod
makisara@kai:~> mt status
SCSI 2 tape drive:
File number=0, block number=-1, partition=0.
Tape block size 0 bytes. Density code 0x26 (DDS-4 or QIC-4GB).
Soft error count since last status=0
General status bits on (9010000):
 EOD ONLINE IM_REP_EN
makisara@kai:~> mt tell
At block 0.

i.e, if the EOD status is set at block zero after 'mt eod', we have blank 
tape. Now, if you have enabled logical block reporting (scsi2logical), the 
filemarks are also counted as blocks. If the tape has only a filemark 
(blank tape initialised with 'mt weof'), I get

makisara@kai:~> mt rewi
makisara@kai:~> mt eod
makisara@kai:~> mt status
SCSI 2 tape drive:
File number=1, block number=-1, partition=0.
Tape block size 0 bytes. Density code 0x26 (DDS-4 or QIC-4GB).
Soft error count since last status=0
General status bits on (9010000):
 EOD ONLINE IM_REP_EN
makisara@kai:~> mt tell
At block 1.

Now eod is set at file 1 (after filemark) at block 1 (there is only the 
filemark).

By combining these two results, you can tell that there is no data on the 
tape.

-- 
Kai