On Fri, 12 May 2000, Ulrich Windl wrote:
> On 12 May 00, at 12:37, Kai Makisara wrote:
>
...
> > My guess is the following: the blocking factor you give tar does not match
> > the physical block size on the tape. The drive is in variable block mode.
>
> This sounds reasonable. However I'm surprised that GNU tar on one
> Linux uses a different blocking factor than GNU tar on another Linux
> system (actually SuSE 6.3 (write) vs. 6.4 (read)).
>
> The write hardware was a Viper Archive (something) and the read
> hardware was a HP-one. I think I can remeber that I saw a message
> when extracting the tape saying something like "blocking factor 1".
>
OK, I will speculate more :-) By default, tar is using blocking factor 20
(10 kB writes). The Linux SCSI tape driver uses whatever parameters the
drive "wakes up" with unless the parameters are changed. If I remember
correctly, Archive Vipers use fixed block mode after power-up (probably in
this case with 512 byte block size). So, the tape is written using 20 tape
blocks for each write() tar does. The HP drives tend to "wake up" in
variable block mode and tar issues read()s for 10 kBs. For each read tar
receives 512 bytes and this is why it suggests that the tape was written
with blocking factor 1.
In this case you can probably best avoid the slow-down by setting the HP
drive into fixed block mode with block size of 512 bytes (mt setblk 512).
You can also use 'tar b 1' but this is slower. In fixed block mode reading
10 kBs of 512 byte blocks needs one SCSI command whereas the variable
block mode requires 20.
Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
