I've had a couple answers like this so I thought I would share my pain... ;)
This is really probably a driver question, but I'm not sure where the best
place to ask would be.

>dd if=/dev/rst0 bs=10240 | tar tvf -

vax@linkdead bash$ dd if=/dev/rst0 bs=10240 | tar -tvf -
dd: /dev/rst0: Mar 21 09:58:42 linkdead /netbsd: st0: block wrong size, 20 blocks residual
Input/output error
0+0 records in
0+0 records out
0 bytes transferred in 12 secs (0 bytes/sec)

Well, I just verified it, and I have _another_ tape that I'm sure
was made by NetBSD - on 1 Dec 1994.  The tape mentioned above was
written 27 May 1995, more than likely written by NetBSD also.  Both
show same behavior.

>Well, by default, tar blocks to a factor of 20, or 10240 byte tape
>blocks (a tar block is 512 bytes).  What more is there to say? :-)

I believe the Linux SCSI HOWTO mentioned something about hardware block
sizes != blocking factor of user-level programs like tar, dd, etc.
They use a berkeley "mt" to do things like "mt setblksz 0" to tell
the tape to obey variable blocking, etc.

The fact that Unix tries to hide all this makes understanding it
2x as difficult.

I also had a problem once reading dump tapes when I upgraded my NetBSD
kernel - this is very bad.  It said, "tape block size(512) is not a multiple
of dump block size(1024)".  This was back on 30 Aug 1995, which probably
is right around when all this started :(

Thanks a ton, this is pretty important to me.