[lkml]   [1998]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: SCSI tape blocks > 128k ?
(Why do these questions always turn up in linux-kernel instead of
linux-scsi or linux-tape ;-(

On Tue, 25 Aug 1998, Harald Koenig wrote:

> On Aug 25, Alan Cox wrote:
> > >
> > > The patch implements the bigbuffer support required for this use, and
> > > patches "sg" to actually use it. A two-line patch will allow st to
> > > also use this......
> >
> > Its a workable answer, but not the right one. The right one is to propogate
> > the use of scatter gather better and eventually (2.3.x I hope) DMA to
> > user pages. Modern SCSI controllers dont need 1Mbyte of linear memory
> > for this. And non DMA old ones are generally sufficiently dumb you can
> > implement scatter gather in the cpu driven byte copy routines
> but at least my setup is just in the middle of these two extremes:
> the DAT is connected to a good old AHA1542B (it's only for external devices
> which can be hot-plughed without risk; I don't need to touch the SCSI bus
> for faster disks), so I need DMA and can't use scatter gather (AFAIK)...
AHA1542B does scatter/gather but (at least in the Linux driver) it is
limited to 16 segments.

I (finally) looked through the SCSI drivers to find the scatter/gather
limits. If I got the results right, there is only one adapter that does
not support scatter/gather (Atari Falcon) and one that supports only one
segment (pluto.c, probably not a problem with tapes). The maximum number
of segments allowed was 16 in several cases and otherwise it was

Let's see what we can do with 16 segments. If we want to allocate the tape
buffer when it is needed, we can reliably use (for x86) 16*4 kB = 64 kB
buffer, which does not improve the current situation. We can use one page
segments and say that the maximum block size depends on the SCSI adapter.
We can try to use larger segments and tell the user that the maximum block
size depends on the history of the system from the last boot:-) I don't
like either of these choices. What remains is some variation of the
current strategy where buffer memory is allocated at boot time so that the
driver can guarantee some maximum block size without holding too much

As you can see, the memory allocation and buffer strategy needs some
thinking and experimentation. (Suggestions are welcome :-) Implementing
scatter/gather in the read and write paths is quite simple because the
lower level SCSI drivers support it. Doing all this is definitely a 2.3
thing. Until then I recommend using the bigbuffer patch and some
modifications to the tape driver.


P.S. _Writing_ larger tape blocks than 64 kB is looking for trouble.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:44    [W:0.034 / U:3.952 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site