>It's worse. With blocksize 0 I get the data and the error, with bs=32k
>I get just the error and 0 blocks read. This applies to ibs/obs=32k
>and bs=32k. ...
There are several moving parts here that I want to make sure we all are
in sync on.
Some hardware has a blocking size. If you set it to zero, that means
variable sized blocks, i.e. what you write is what goes on the tape.
Setting to some power of 2 (the usual way it's done) will take a 32 KByte
block from Amanda and write multiple physical blocks. Through some magic
I've never understood, when the data is read it comes back looking like
a single 32 KByte block to the application.
The important thing with hardware blocking is that you be consistent.
If you write with one hardware block size, change the size and try to
read it back, bad things will happen.
I, personally, prefer to use variable sized blocking because it matches
my ancient dealings with tapes. But you could use most anything you want,
again, as long as you are consistent.
Now, when you give dd a block size, that's the size of the buffer that
is handed to read and expected to be returned. Most drives (and kernel
drivers) will report some kind of error if you do not ask for enough
data, i.e. the dd block size is smaller than the physical record size
(32 KBytes in the case of Amanda). Note that this is not the same as
the physical block size.
It's not an error to ask for more data than is in the physical record --
that just gives you back a short read.
>Amanda should set the block size anyway.
I'm not sure which block size you're referring to. You're correct that
Amanda will do read's of 32 KBytes. But controlling the hardware block
size is highly OS dependent (if it's possible at all -- it's not on
Solaris, for instance, without a reboot)
>Maybe Amanda should not trust all SCSI errors.
Amanda has no idea a SCSI error happened. All it got back was an EIO
indication from the read. That is the complete sum total of information
it has available to it.
For your problem, I'd first start by getting the hardware block size
under control and consistent (if it isn't already). I'd also check the
DIP switch settings on the drive and make sure they are not overriding
things or doing other wonderful stuff.
Then I would take a scratch tape and write several files of varying
length (including an initial one of a single block), all with 32 KByte
record sizes. Then try to read them back.
It looks like the first data record is OK, but the drive is having
trouble sensing or dealing with the tape mark that follows.
>Johannes Niess
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
