"John R. Jackson" <[EMAIL PROTECTED]> writes:
> >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'm consistently on variable size.
[...]
> It looks like the first data record is OK, but the drive is having
> trouble sensing or dealing with the tape mark that follows.
My workaround is "amlabel -f taeglich taeglich7" every time I insert
tape taeglich7. The combination rewind/read fails (as seen on all
other occasions); the following write/read succeeds. Amflush after
that works fine.
The tape is forced to SCSII 2 and no hardware compression. What are
the differences between SCSII 2 and 3 with regard to tapes? Anything
applicable in my case?
Johannes Niess
