Output blocksize on Fujitsu 9-track
Colonel Panic
hue at island.uu.net
Wed Dec 19 19:55:17 AEST 1990
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
More information about the Comp.sys.sun
mailing list