[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-scsi
Subject:    Re: i/o error with larger QIC
From:       J Wunsch <j () uriah ! heep ! sax ! de>
Date:       1999-04-25 13:06:47
[Download RAW message or body]

As Stephen McKay wrote:

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

But well, why are we using `pretend' variable length blocks on the
other tape drives then?  Everything except half-inch pretends the
variable-length recording (with more or less restrictions).  Just to
verify this assumption, i've fetched the Exabyte 8mm SCSI reference,
and they're basically doing about the same as QIC >= 320.  They use
the same 1 KB physical blocks (with some more ECC data due to the
nature of the helical-scan recording -- 400 bytes per each 1024 data
bytes on 8 mm, as opposed to 2 physical 1024-byte blocks per each 14
physical data blocks on QIC).  So, whenever you use those drives in
variable-length mode (and i'm sure this applies to DDS and DLT as
well), the drive actually splits the data to fit into physical blocks.
The emulation may be better or worse, depending on the actual
implementation, but who cares?  The main differences i'm seeing
between EXB 8mm and QIC >= 320 are:

. The two more modern 8mm formats (8200c and 8500) can start logical
  blocks at arbitrary positions within a physical block, so they don't
  have to pad blocks.  The old 8200 format is similar to the QIC way,
  logical blocks could span multiple physical blocks, but the remainder
  of the last physical block up to the next block boundary is padded.
  (There's one exception to this, i. e. two 512-byte logical blocks
  can share one 1024-byte physical QIC block.  Thus, 512-byte fixed-
  length recording doesn't waste space on QIC.)

. QIC only accepts three possible block size settings: 0 (variable),
  512, 1024.  8 mm accepts everything up to 240 KB.  I don't know how
  other tape systems behave here, but i haven't seen anybody who would
  use odd fixed-length blocksizes either, so it's probably rather a
  mood point.

> 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

I'm not sure whether this is a feature of the Tandberg only, but i
don't care right now.  You're probably right, this returns short
blocks.  OTOH, my test series defeats your idea :), under some
situations the data rate went up to the full QIC-525 speed again even
for this combination.

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

In my case, it was dump's default of 10 KB.  From my experience,
bumping it over 10 KB doesn't affect the overall throughput much, and
beyond 32 KB, you'll hardly notice any improvement at all.  So i
figure this wasn't the key point in my measurements.

> $ 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. :-)

Because it's obsolete. :)  Nobody uses it on the other tape drives
either (even though all of them, of course, implement it).  I have no
problems with the speed in variable-length mode either, as long as the
application is using a large enough block size.  Speedwise, it makes
no difference whether you pass the 32 KB in one transfer to the tape
drive, and then have the tape considering it as a single logical
block, or as 32 logical blocks (that are incidentally same length as
the physical blocks then) of 1 KB each.  OTOH, with variable-length
mode, you can always get some data out of any tape, regardless how it
has been written (provided your application uses a large enough
blocksize at all to hold the blocks -- dump and GNUtar seem to work
OK).

Again, if fixed-length recording were that good, why don't the other
tape drives use it?  I think the only reason for using fixed-length
recording on QIC (>= 320) is history...

(Of course, with QIC-120/150, this differs a lot.  The variable-length
emulation there imposes so much restrictions that it's practically
useless, and despite of it apparently being a QIC standard, i wouldn't
be so sure whether all the QIC drives would really grok such tapes at
all.)

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

OK, it's only that my mailer can special-case replies to mailing
lists, so _not_ keeping people in the Cc list is somewhat simpler for
me.  But i can honor your wish, no problem.

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

[prev in list] [next in list] [prev in thread] [next in thread]