Third-party SCSI data transfers
Bob.Snively at eng.sun.com
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.
More information about the T10