[Info-vax] Backup TK50 tapes

[Bob Koehler]

In article <kgishn$fq0$1 at speranza.aioe.org>, glen herrmannsfeldt <gah at ugcs.caltech.edu> writes:
> Bob Koehler <koehler at eisner.nospam.encompasserve.org> wrote:
> 
> (snip, I wrote)
>>> I have read/written 100K on unix 9track drives. 
>  
>>   One 100K block?  Or a series of reads totaling 100K?
> 
> I haven't done it so recently, but I thought I remembered doing
> it with either tar or dd. 
> 
> According to man st (SCSI tape) on my Linux system, earlier kernels
> allow 128K on 32 bit systems and 256K on 64 bit systems, with a
> buffer allocated as one block. Newer kernels can allocate the buffer
> in up to 16 pieces, for 2M or 4M block size.

   Allocating blocks in RAM is different from the block sie transfered.
   We had 4MB buffers allocated in RAM on our 11/780, but the MASSBUS
   and UNIBUS could not transfer using lengths in more than 16 bits.

   Even the DR780, which is a lot like an IBM channel, did semi-infinite
   transfers as many smaller blocks.

> For S/360, you can write larger blocks with data chaining. That is,
> more than one CCW for the block. (Among others, it allows for
> scatter/gather I/O operations.)  Also, as you say, the timing is
> critical. CCWs have to be fetched from memory (self modifying 
> channel programs, or system modifying while they are running,
> are both allowed). So, the channel has to fetch the new CCW and
> continue the operation while data transfer continues.

   Exactly what the DR780 did.  But that doesn't mean the I/O device at 
   the other side of the CCW has an inifite number of bits in its length 
   register.