Re: SCSI tape problem

[Stefan Hensen <hensen%wpos4.physik.uni-wuppertal.de@localhost>]

On Fri, 17 Apr 1998, Ignatios Souvatzis wrote:

> Stefan Hensen wrote:
> 
> >   st0: bad request, must be between 33925 and 16777215
> 
> Hm... looks like the tape can only use variable block sizes in certain ranges.
> 
> You should switch it to a convenient fixed blocksize once (which is what
> tar, dump, etc. use anyway) which is a multiple of 512 bytes.

Well, after trying this, it seems that it doesn't solve the problem ...
However, it led me to the right direction for some additional tests
(before, I didn't think of blocksizes when I saw the above mentioned
error message):

The 'mt blocksize <value>' command accepts values form the range mentioned
above or 0 (for variable blocksize). Other blocksize values result in:
   mt: /dev/nrst0: blocksize: Invalid argument
As expected, 'mt status' reports a previously set value. But after the next
'tar' command, which may or may not work (see below), 'mt status' always
reports a value of 0. Therefore, it's not possible to set a fixed value
once and then leave it as it is. Probably the "mount session" ends
automatically after 'tar', but that's not really the problem ...

The 'tar' command works only, if the b-option is used with a value that
gives a blocksize in the above mentioned range (i.e. the default value b=20
for a blocksize of 10240 bytes does not work!). This is independent of any
'mt blocksize' command being used or not.

A tape written by tar with an appropiate b-option value can only be read
without errors, if the same option is explicitly set in the read command.
If the tape was written with a blocksize different from that specified in
the read command (even if they are both in the "allowed" range), the tape's
blocksize is displayed on the screen, but during reading there appear lots
of errors like:
   st0(flsc0:4:0):  Check Condition on opcode 0x8
       SENSE KEY:  No Additional Sense
                   Incorrect Length Indicator Set
      INFO FIELD:  14336
        ASC/ASCQ:  No Additional Sense Information
They seem to be repeated for each tape block.
My understanding was so far, that the blocksize of an existing tape is
automatically recognized (which seems to be the case) and used (which seems
not to be the case). The current situation seems to make it impossible to
read tapes that have been written by other systems with their default
blocksizes.

The question is: Where does this blocksize range of 33925 to 16777215 bytes
come from???

With AmigaOS, I successfully use a blocksize of 10240 bytes, corresponding
to the default value of 'tar', to be able to read/write tapes from/for unix
systems. Furthermore, I use exactly the same type of tape streamer with
Digital Unix/Alphastation and Linux/PC systems and there have never been
problems with a blocksize of 10240 bytes (and also not with tapes written
with blocksizes different from the default one).

So the tape streamer (HP 35480A) definitely can handle this smaller block
size. Therefore, I suspect that it is a problem of NetBSD ...

Actually, all this was quite surprising for me, because I had already used
the tape streamer successfully with an earlier release of NetBSD/Amiga with
one of those pre-1.1 kernels, where the "old version" of the Fastlane
driver appeared for the first time. (I couldn't test it with NetBSD 1.1 and
1.2 because of the strange "one device only" problem with the Fastlane
driver of those releases.)

Regards,

Stefan Hensen

----------------------------------------------------------
Stefan Hensen
e-mail: hensen%wpos4.physik.uni-wuppertal.de@localhost