The size of I/O depends on your hardware. In the SCSI world, it
requires that the port AND class driver support larger single
I/O requests. The basic $QIO system service on Alpha accepts
transfer sizes of up to 32 bits' worth of bytes (I'd limit it
to 31 for safety though...).
There are a number of SCSI port drivers...most of the current
generation in fact...that for one reason or another can handle at most
64K at a time. The drivers break this up for you. We are looking at
supporting longer I/O, but be aware that this may well be handled as
a site override of some sort, since huge I/O could tie up the bus
between commands for longer than we like to see it in general
purpose situations.
Another point to be made: the measurements of SCSI driver performance
on several adapters indicate we are driving them at pretty close to
their maximum I/O rates, and the internal splits into 64K units may
not be the bottleneck here. We are working also on getting faster SCSI
controllers and wide support, and in fact wide SCSI drives are working
in house on several controllers now. Wide drives have twice the data
rate limits and are appearing on the market.
Your I/O drain devices (tapes? disks?) may want to be on different
busses than the I/O source ones.
Some other performance boost techniques are also in the works in the
SCSI space.