Third-party SCSI data transfers

Bob Snively Bob.Snively at
Tue Sep 13 07:11:15 PDT 1994


Your last item, number 8, is the most telling arguement against
placing the SCSI protocol on TCP/IP.  NSF and similar access
protocols use a very simple abstraction of a file to obtain information
without all the low-level management typically used by SCSI
drivers.  They also hide the physical and even the logical block
structure of the files under a powerful access mechanism.  By
placing the SCSI driver on the host side of the TCP/IP connection,
you require the host to be aware of all the low-level SCSI command
requirements and essentially nest a fully SCSI driver on top of the already
somewhat inefficient TCP/IP driver.

I would expect that the performance of a well-designed TCP/IP
program accessing a well-designed NSF server would be a far better

Additional problems include the requirement to perform full command-parsing
of the SCSI command set on the target side above the TCP/IP driver.
This provides a latency that eliminates the perceived advantages.

Another problem is that the amount of data needed to fullfill an
abstract request may be quite significant from the drive, but relatively small
through the NSF protocol.  The result is that you increase the bandwidth
requirements on the network with no decrease in the amount of the 
processing or SCSI disk resources requested.

All in all, I think it is not a good trade.

Bob Snively

More information about the T10 mailing list