Path: utzoo!attcan!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: hue@island.uu.net (Colonel Panic)
Newsgroups: comp.sys.sun
Subject: Re: Output blocksize on Fujitsu 9-track
Keywords: SunOS
Message-ID: <901@brchh104.bnr.ca>
Date: 19 Dec 90 08:55:17 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 34
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v9n391, Replies: v9n397
X-Sun-Spots-Digest: Volume 9, Issue 410, message 1
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

In article <747@brchh104.bnr.ca>, wsrcc!wolfgang@uunet.uu.net (Wolfgang S. Rupprecht) writes:
> henry@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@island.com