Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 Apr 1999 20:30:34 +0200
From:      J Wunsch <j@uriah.heep.sax.de>
To:        freebsd-scsi@FreeBSD.ORG
Subject:   Re: i/o error with larger QIC
Message-ID:  <19990422203034.22930@uriah.heep.sax.de>
In-Reply-To: <199904221512.BAA10969@nymph.detir.qld.gov.au>; from Stephen McKay on Fri, Apr 23, 1999 at 01:12:52AM %2B1000
References:  <7F6ncL5zoRB@subloch.medicusnet.de> <199904221512.BAA10969@nymph.detir.qld.gov.au>

next in thread | previous in thread | raw e-mail | index | archive | help
As Stephen McKay wrote:

> Do you mean 1024 bytes?  If 'mt blocksize 0' doesn't work, then using
> 'mt blocksize 1024' should work.  The normal block size for these tapes
> is 1024 bytes.  It's really silly to use anything else for QIC525.

Huh?  Every QIC-525 tape i've seen so far seems to have used variable-
length recording.  Sure, the underlying tape has to impose a blocksize
(of 1024 bytes), but that doesn't mean logical blocks could not be of
variable size.  I have to look at my girlfriend's TDC3820 again (with
FreeBSD pre-3.0, and the old SCSI system), but i'm almost sure this
used to be the case.

According to the Tandberg manual, even QIC-150 is able to perform
variable-length recording, but this always wastes one 512-byte block
for recording the logical block length, whereas QIC >= 320 seems to
record the logical block length somewhere outside the physical blocks,
so no space wasted as long as you write in multiples of 1024 bytes
(which probably everybody does anyway: tar uses 10 KB, dump 10 or 32
KB, depending on the tape length).

Just to verify this, i dug up an old QIC-525 cartridge, and put it
into the TDC4222 drive under a fairly-current system.  Running `tar t'
succeeded immediately since the driver had already been forced into
variable mode (which i'm currently doing from rc.local to work around
the driver problems).  Looking at the tape's contents, it looks like
the cartridge has once been written on a Linux/AXP machine, so it
seems the interoperability in `variable' mode is fine.  Hmm, hmm, i
notice the `tar: Blocksize = 1 records' on top, so this probably means
the tape has been written in 512-byte records?  At least, i notice a
very poor performance.

Yup, this really seems to have been written using 512-byte variable-
length recording.  Interestingly enough, using 512-byte fixed-length
mode seems to much improve performance when reading.


This triggered me to make a few experiments with dump (all done on a
TDC4222 with a QIC-525 cartridge).  Speeds are excluding the tape
rewind time (which is varying unpredictably due to the serpentine
recording).

write			read speed using blocksize
blocksz	speed		f/512	f/1024	v/10K	v/32K
				**

v/32K	179K/s		+	+	*	188K/s
v/10K	179K/s		+	+	190K/s	(190K/s)
v/1024	104K/s		+	137K/s	(81K/s)	(81K/s)
f/1024	179K/s **	++	133K/s	83K/s	82K/s
f/512	179K/s		87K/s	121K/s	191K/s	192K/s

() Values in parenthesis are modi that are possible but not much
   useful, since they return short blocks.

+  IO error

++ IO error plus ``Invalid request.  Fixed block device requests must
   be a multiple of 1 bytes'' (apparently some bug there)

*  not useful, since only partial blocks would be retrieved, so
   the remaining data in each block were lost; IMHO this should rather
   yield an IO error instead (which it did in previous FreeBSD versions)

** blocksize currently needs to be manually adjusted back to 1024
   after each tape operation, since the driver resets it to 512

To summarize:
-------------

Variable-length logical blocks seem to work best, ever.

Fixed-legnth blocks (either 512 or 1024 bytes) have problems with read
speed.  This seems to be a driver problem, in particular since the
read speed using variable-length read operations is better.  Given
that the best possible values are at best en par with the variable-
length recording values, i don't see why anybody would use fixed-
length mode.

The driver seems to have bugs, see ++ and ** above.  Btw., `mt stat'
reports compression 0x3 everywhere, although i know that only QIC-2GB
and above support compression at all.  Maybe this is part of the
problem?

Slow speeds above are accompanied by the tape going in `start-stop'
mode.

-- 
cheers, J"org

joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990422203034.22930>