On Sun, 29 Nov 1998, Popov wrote:
> Steve Austin wrote:
>
...
> > The problem may be to do with your SCSI adaptor or the drive itself; I
> > have been successfully reading and writing 128K blocks on an HP C1599a via
> > an Adaptec 2940 without difficulty (other than a hardware fault in the
> > drive itself) and without modifying the 2.0.32 kernel I've been using.
>
> I would have to agree here with the above email. By default, the kernel
> imposes a 32k limit which you can easily modify and recompile the st
> module. dd and tar might accept larder block sizes, but the lower level
> driver will break up the transfer in 32k chunks at a time.
>
The default tape buffer size is 32 kB. However, if a larger buffer is
needed, the driver tries to allocate it. In 2.0.x, the buffer has to be
contiguous in the physical memory. This means that the upper limit is 128
kB. Whether allocation of the temporary buffer succeeds, depends on the
fragmentation of the system memory. At least one block must fit into the
buffer. So, if someone claims that he/she has used 128 kB blocks with the
default parameters, the run-time allocation has succeeded.
The SCSI tape driver in the recent 2.1.x kernels uses scatter/gather with
the tape buffer. This means that the upper limit of the buffer size is not
constrained by the kernel allocator and that the chances in enlarging the
buffer when needed are much better. There are again driver options you may
want to change if you want ridiculously large blocks.
The file linux/drivers/scsi/README.st explains the buffer allocation
strategy.
Kai
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
