Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 23 Apr 1999 18:46:38 +1000
From:      Stephen McKay <syssgm@detir.qld.gov.au>
To:        freebsd-scsi@freebsd.org
Cc:        syssgm@detir.qld.gov.au
Subject:   Re: i/o error with larger QIC 
Message-ID:  <199904230846.SAA01231@nymph.detir.qld.gov.au>
In-Reply-To: <19990422203034.22930@uriah.heep.sax.de> from J Wunsch at "Thu, 22 Apr 1999 20:30:34 %2B0200"
References:  <19990422203034.22930@uriah.heep.sax.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, 22nd April 1999, J Wunsch wrote:

>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.

Interesting.  I've used fixed 1024 byte blocks all the time to avoid
the hassles of pretend variable length blocks.

>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.

You are seeing a "feature" of the Tandberg, as far as I can tell.  It
will read fixed block tapes in variable mode, but very slowly.  It is
slow because every read() is satisfied by only 512 or 1024 bytes.  If
you were using fixed block mode, then each read() would return 10K or
more (I use 32Kb for everything).   Try using (say):

	dd if=/dev/rsa0 of=foo bs=32k count=10

and you will see 10 partial reads in variable mode, totalling 5K or 10K,
and 10 full reads in fixed block mode, totalling 320K.

[Interesting table removed]

>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.

But what block size did the application use when the tape was in fixed
block mode?  This is important, and affects the throughput.  Eg, I use:

$ mt blocksize 1024
$ tar cbf 64 /dev/nrsa0 foo bar bletch

to use fixed block mode, but 32Kb transfers.  I have no trouble keeping
the tape streaming.  So I don't see why anybody would use variable
mode on these devices. :-)

>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?

Yes, there are some bugs and misfeatures.  I can test fixes, or if people
are very patient, I can attempt to produce fixes.

Stephen.

PS Jörg, I know you don't like to be in the cc: list of responses, but
since I turn my list mail into news, keeping me in the cc: list means
I won't miss anything!


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?199904230846.SAA01231>