Output blocksize on Fujitsu 9-track

[Colonel Panic]

In article <747 at brchh104.bnr.ca>, wsrcc!wolfgang at uunet.uu.net (Wolfgang S. Rupprecht) writes:
> henry at zoo.toronto.edu (Henry Spencer) writes:
> >You don't specify what controller your magtape drive is on.  For a guess,
> >it's a Xylogics 472.  The byte-count field on that controller is 16 bits.
> >It is incapable of writing a block bigger than 64K-1 bytes.
> 
> SCSI itself has a similar limit.  Thats why one can't get more than 126
> blocks of 512 bytes in one tape read or write.

Wrong.  The obvious reason why there is a 63K limit is that most device
drivers don't supply their own minphys(), but just hand physio() the
default minphys(), which (historically) limits the size of raw I/O to 63K.
I believe this dates back to limitations of the UNIBUS mapping registers
on the PDP-11.  (I'm not that old, I just heard this and it made sense)

This means you'll probably not be able to write a tape block > 63K even if
the tape controller supports it.

[41]island:hue: adb /vmunix
minphys?6i
_minphys:
_minphys:		linkw	a6,#0
			movl	a6@(8),a0
			cmpl	#0xfc00,a0@(0x14)
			bles	_minphys+0x1a
			movl	#0xfc00,a0@(0x14)
			unlk	a6

Hmm, looks like a brave (or foolish) soul could kick this number up if
they had only a binary of the device driver and really wanted to see if
they could get xfers > 63K.  I bet there are drivers out there that depend
on their strategy routine never being passed a buffer with b_bcount >=64K.

Jonathan Hue	Island Graphics Corp.	uunet!island!hue   hue at island.com