[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: tar/tape



Gavin:

On Tue, Feb 24, 2004 at 01:03:34PM +0100, Dr Gavin Seddon wrote:
> Hello,
> My tape drive is a hp 20 40 scsi drive.  It will allow data to be
> written to it.
> 
> The output of mt -f /dev/st0 is:
> 
> root@genesis:/home/gseddon# mt -f /dev/st0 status
> SCSI 2 tape drive:
> File number=0, block number=0, partition=0.
> Tape block size 10240 bytes. Density code 0x13 (DDS (61000 bpi)).
> Soft error count since last status=0
> General status bits on (41010000):
>  BOT ONLINE IM_REP_EN
> 
> There is a symbolic link between /dev/st0 and /dev/tape.  I have tried
> mt setblk 10240.  Still the device stops, with the same error.  However,
> some data is written to the tape.
> 
> Gavin.

Your drive and mine are very similar (both HP, although model numbers
are different).  The status returns:

      p4:provinsd@ve6wvc:~ 4$ rsh ve6cta 'mt status'
      drive type = Generic SCSI-2 tape
      drive status = 318767104
      sense key error = 0
      residue count = 0
      file number = 0
      block number = 0
      Tape block size 0 bytes. Density code 0x13 (DDS (61000 bpi)).
      Soft error count since last status=0
      General status bits on (41010000):
       BOT ONLINE IM_REP_EN

but /dev/tape points to /dev/nst0 (the no rewind version).

I notice in your status that a partition number is mentioned (zero).
I have NOT partitioned any tapes (as I recall, a tape can have 2
partitions of presumably arbitrary size).  Thus I can write until I run
out of tape.  If (by chance) your tape has a small partition followed by
a large (the remainder of the tape) partition, then "tar" may be hitting
the limit of that first partition.  In this case, either:

	repartition the tape to a single partition, or
	move the tape to the second partition and try "tar" there.

But I don't see a way of using "mt" for any partition adjustments, so
I suggest you get an unused tape (new) tape.  I suppose the alternative
would be to alter "mt" to allow the needed adjustments, but that may be
more than you (or I) might be willing to try.  However, by your comments,
I presume that you tried the write test that I suggested.  It would only
verify that several short records could be read and written.  Try a bigger
test to see if you find the write limits.  The following comes to mind:

	dd if=/dev/zero of=/tmp/zeros count=50 obs=1024 ibs=1024
	dd if=/tmp/zeros of=/dev/nst0 ibs=1024 obs=1024 count=50

The first statement will create a file of 50*1024 bytes of zeros.
The second will write it to the tape in no rewind mode.  If the partition
to which it is writing is smaller than 50*1024 bytes, it will fail, but
tell you how many blocks were written.  From that you can confirm that
the partition is smaller than the amount of that you intended to write.
If that is the case (I expect 4*1024, given your previous post), then
the reparitioning, or tape replacement will be your only alternative.

Incidently, I use 90M tapes (and some 60M tapes that I picked up
cheaply).  They are DDS-90 data tapes.

Dean

PS:  As this may be a problem that others experience, I am posting this
to the Debian list, as well as CCing you.

-- 
				Dean Provins 
			    50.950333,-114.037916
			  provinsd@telusplanet.net
		  KeyID at at pgpkeys.mit.edu:11371: 0x9643AE65



Reply to: