I have a problem with the scsi-tapedriver. The story is this:

When you issue a command like:
	dd if=/dev/zero of=/dev/rst0 bs=1k count=10
and you read it back with:
	dd if=/dev/rst0 of=/dev/null bs=1k

You will get 11 blocks back. I have turned on some tracing in my (atari)
driver, and what I see is, that the read command fails on the 11th block
with residual count (xs->resid) 1024, xs->error = XS_SENSE. The sense data
returned is: 0xf0 0x00 0x80 0x00 0x00 0x00 etc.
This means that a Filemark is detected _and_ that the info bytes are valid.
The st-driver interprets this as: The residual is 0 blocks, and overrules
the residual in xs->resid. Thus telling the upper-layer that the transfer
has succeeded. The manual of my Tandberg 3600 is rather vague about the
behaviour of a read-command hitting FM. I tried out some things, and it
turned out that they always report a residual of 0 blocks. Even when
you try:
	dd if=/dev/zero of=/dev/rst0 count=11
	dd if=/dev/rst0 of=/dev/null bs=1k
	6+0 records in
The last command has a residual of 512 bytes on the last block, but the
tape returns a residual of 0!?
It looks as if the residual count in the sense data means:
  The number of blocks left to transfer _before_ hitting FM

Seems that it is safer in this case to follow the residual count of
the driver than overruling it with the residual count of the sense-data.

Leo.