Slashdot Mirror
HyperSCSI Examined
An anonymous reader writes "Eugenie Larson of byteandswitch.com has published a brief article that reviews the HyperSCSI protocol, which like iSCSI allows for an IP based san. The twist of HyperSCSI is that it's opensource, and runs over raw ethernet, avoiding the overhead of TCP/IP. The article has some comments from early adopters of HyperSCSI, as well as some comments from top vendors in the iSCSI industry."
I like the idea. Ethernet hardware is dirt cheap and fast. What it needs is a cheap IDE bridge board. That would let you put some IDE drives in an external enclosure and plug them into the local LAN.
Mea navis aericumbens anguillis abundat
Fiber Channel maximum cable length: 10,000 m
Add the appropriate routers and switches and you can easily go 90 km on dark fiber. Add some appropriate routers onto a fast network (T3, ATM, what have you) and you can go 500 km. With fast FC connected storage at each end. Of course, this sort of solution is used by data centers, not home users. But Fiber is the obvious solution to data storage problems. And there is enough mass in the server storage market now that prices are starting to come down. Of course, if you need fast, redundant, capable storage you won't blink at the cost.
In my universe I'm perfectly normal, it's not my fault you don't live in my universe.
That's a good point, and needs a bit more modding up.
...) evolved for the long thin pipes used to connect computers to one another.
It's worth adding, however, that the hyperSCSI folks are trying to make a distinction between wider-area networks (which they call SWANs for Storage WAN) and local single-segment (since they aren't routing) networks, and arguing that iSCSI is right for the former and hyperSCSI, because it's faster/cheaper, for the latter.
This view has parallels in the history of NFS over TCP versus NFS over UDP, because NFS/UDP is still hanging on in one niche: short-haul, high-speed, low-latency, few-hops, negligible-loss environments.
It also has parallels with the bad old days when direct-attached storage interconnects were much faster than LANs, so one set of protocols (FCP, SCSI, ESDI, IDE, SIMD...)evolved on the short fat pipes used to connect computers to peripherals, and a completely different set of protocols (ethernet, TCP/IP, SDLP,
Similarly, hyperSCSI is an argument that the two domains are different enough to justify different protocols. That seems to be arguing against a historical trend tht says that the short/fat and long/thin differences are vanishing; compare gigE and fibrechannel as _wires_ today.
All of this just reinforces Bourne's general point about ignoring the history. It's pretty clear that NFS over TCP is where the world is going, and the only reason that there's an NFS over UDP hanging around is that's how all NFS used to be, so some still is. When we compare hyperSCSI to iSCSI over TCP, I can't find any reason not to just deploy iSCSI everywhere and be done with it.
Because the IP checksum and TCP checksum occasionally disagree about the packets' validity in real-world routers and operating systems - they are both needed to provide redundancy and robustness. Stevens' TCP/IP Illustrated cites [Mogul 1992] providing counts of checksum errors on a busy NFS server:
Layer Total packets # chksum errs
Ethernet 170,000,000 446
IP 170,000,000 14
UDP 140,000,000 5
TCP 30,000,000 350
Basically, when absolute accuracy is required the more error checking the better.