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."
With all it's error correction and what not! Who needs that for data stoage?
I read somewhere that it's like 5 times faster than SCSI over TCP/IP. Is it true? And how great is the sacrifice of not using TCP/IP? I mean, what doesn't support Ethernet these days?
The summary says "IP based" then "without the overhead of TCP/IP" and then "raw ethernet".
Which one?
Can't be both IP based and raw ethernet at the same time.
You don't expect us to RTFA do you?
"avoiding the overhead of TCP/IP"
yet you can tunnel IP inside of it... adding a layer of overhead for IP.
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
why is there an article on this, i mean linux wont support it for another 2 years lol obviously, it's so when linux does support it, legions of slashbots can complain about the duplicate stories!
Do you even lift?
These aren't the 'roids you're looking for.
and
Mmmm.. beer can with motor.If you look go to the MCSA site and look at the HyperSCSI FAQ, it does implement reliability and flow control, just not in the same manner as TCP.
The only technical negative side I can (at this time) is that because the implementation isn't over IP, you can't traverse a router. This usually isn't a problem but could cause some inflexibility in larger deployments.
What is this?
And this is a technology breakthrough? I wouldn't want my data travelling down a wire with no error recovery no matter how small the error rate.
From excellent karma to terible karma with a single +5 funny post...
and
obviously, it's so when linux does support it, legions of slashbots can complain about the duplicate stories!
From the article:
Read, L
Two big disadvantages:
First, Ethernet can't be routed, so hyperSCSI isn't going to be nearly as flexible as iSCSI. This is the reason that just about everything that might want to be routed is usually carried over IP (and TCP and UDP and other stuff on top of IP). Straight ethernet is for stuff like ARP that really doesn't want to leave a network segment.
Of course, one could reasonably do something hyperSCSI-like across IP, and still save the TCP overhead. (Consider that in a low-loss short-hop environment, NFS over UDP generally outperforms NFS over TCP). The problem here is that SCSI was never ever intended to run well over a lossy transport, and it doesn't. That seems a serious objection to running SCSI over both non-routable and non-reliable ethernet and routable but still non-reliable IP.
C'mon, there's a reason why people use TCP....
And why iSCSI chose TCP as the transport....
Vanilla Ethernet can be extremely reliable, without any additional layered protocols. I would be much more concerned about the reliability of the installation's AC power supply and distribution system.
Mea navis aericumbens anguillis abundat
But I'd prefer to use it over gigabit ethernet, or at the very least a separate ethernet device than the one I use for me lan.
Can multiple computers access the same drives through this?
On another note, is it possible to network over traditional SCSI, by changing the SCSI card ID's to make them co-operate on the same chain? Does an implementation of this exist in Linux, *BSD, or Solaris?
You can't judge a book by the way it wears its hair.
Use loose and fast HyperSCSI on your local segment where it's possible, and use a concentrator that translates into iSCSI over IPSEC for secure WAN connectivity.
That way you only need to buy one TOE card per WAN edge. Those can get expensive!
Fuck Beta. Fuck Dice
SCSI is dead? For the home computer perhaps, but not in the data center. I have yet to see a serial ATA enclosure perform on anything like the level of enclosures using SCSI over FC. Why don't you go look around a large office environment or a data center and see how many storage devices are SCSI based. This stuff (iSCSI, HyperSCSI, Ultra320, etc.) are aimed at servers and storage networks, not your desktop PC.
In my universe I'm perfectly normal, it's not my fault you don't live in my universe.
This is great for folks that want to be locked into a single vendor without any path to get out
Didn't the article state that HyperSCSI is GPL and runs on Linux? What the fuck is this guy talking about?
SCSI is dead
Many people here disagree with you. I wish I had SCSI hardware... you troll... now you've hurt my feelings...
tuned for SCSI commands and data transfers. This is the particularly interesting part of the protocol. It assumes you're going to be doing bulk transfers, and lets both ends negotiate windows for performance (as opposed to using a sliding scheme).
As I see it, the real problems:
- SMP "experimentally" supported
- client and server can't coexist on same box
- client model is not decoupled enough from the server (a server going down can mean the client could crash)
It appears the driver software needs some work properly implementing what seems to be a nifty protocol. And they want to port it to Solaris. I think they should get the locking and stability down first.
Fuck Beta. Fuck Dice
The NICs are cheap and the prices of the switches are dropping. I don't think it will be that long before gigabit Ethernet starts to push 100 Mbit Ethernet out of the market.
Mea navis aericumbens anguillis abundat
If it is truly raw ethernet, this means that you cannot route it. On most current networks, you probably wouldn't want to because of latency issues, but, on networks with 1 gig or 10 gig links, latency should not be a problem. So, if it does use raw ethernet, this is actually a limitation of it, not a benefit.
Need Free Juniper/NetScreen Support? JuniperForum
More to the point, we have usb 2, serial ata, and firewire. Really all you should need is usb 1.1 and firewire in ever-increasing speeds, besides your display output. There's literally no need for anything else. Firewire can be operated in a synchronous fashion, after all. It supports lots of devices per adapter (63 or 127 depending on implementation) and comes in powered and unpowered as well as peer to peer or host-based forms, but nearly all devices will fall back to the lowest, slowest mode - which is capable of 400Mbps per second, or 50 Megabytes, clearly enough for all but the fastest hard drives, and nearly any other use to which you might put it. 800Mbps firewire is available today, and 1.6Gbps is uh, just over the horizon or something. They claim they'll do 3.2Gbps over fiber in the near future as well, but I'll just stick to developments just over the horizon, not way over it, here.
Frankly what I want to see more than anything is native 1394 storage devices. 1394 is somewhat to scsi (it would kind of have to be, wouldn't it?) and is at least well documented. I want hard drives that have only power and 6 pin 1394 connections on them, pass through style. You could treat them basically like an external scsi chain not requiring termination, but inside your PC. Firewire to IDE bridges are not the answer, they just make things more complicated and firewire is supposed to make things less complicated, though I suppose they are a sort of interim solution.
For the average user, if you could get native (and thus inexpensive) firewire solutions for everything, it would fulfill your needs much better and would make computer use much simpler. The only thing you need besides firewire and USB for every common peripheral is video output and possibly high speed networking, perhaps provided from a MII or similar connection, just as AUI was the standard at one time. Just, without the annoying box and cables. And let us not forget, a memory slot. I assume most people would also like to have wireless ethernet with an external antenna jack. For the rest of us, we would continue to run our however-shaped boxes with internal expansion, PCI-Express or what have you, and our cabling would be much simplified. Once again, 800Mbps is 100MBps, yes? Assuming you can only really sustain 50 or 60% of that with multiple devices competing for the bus, that's still fast enough for basically any two hard drives anyone is likely to have at home. So 800Mbps firewire is perfectly adequate to the task of connecting hard drives today. It's not that SATA isn't, it's that having less types of interface simplify a computer. If you're only going to have two interfaces, you will get more mileage out of USB2 and IEEE1394 than you will USB2 and SATA, even one of the bastardized forms of it like External SATA, if people will just make IEEE1394 devices.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I believe you could say exactly the same on Novell. "Yea, that thing is for serious users and not for your typical mother's girly who want to share a folder with her mom". And maybe what you said is right for now, but let's face it, SCSI is passe. You can't compare its big flat connector to the elegant Serial ATA wire.
SCSI may try to continue living, but it got only one direction to go: history's garbage pail.
I've got SCSI hardware supplied with my CD-RW. And it didn't make me feel happier. Not at all.. my friend here bought an ATAPI burner and he's laughing all the way on me. "You sucker.. you paid so much more just to be able to say you got SCSI. And guess what? it's gonna die!".
Fiber Channel SANs aren't based on IP either, yet people manage to do off site replication with them.
I don't know how far away you want to put your off-site backup, but Cisco have been selling a GBIC (Gigabit Interface Converter ? Too many FLAs for my head these days), which they've been calling 1000BaseZX, which will send an GigE signal around 90 Kilometers over single mode fibre.
Even Full Duplex Fast Ethernet over multi-mode fibre will go 2 Kilometers.
You can build some really big ethernet networks these days. I don't think the non-IP thing is all that much of an issue.
Although the idea of using cheap commodity equipment like ethernet is to rationalise multiple networks down to a single IP network, there are also good reasons to using commodity ethernet to build a separate network for your storage, security being the main one. It probably wouldn't be too good to have CodeRed or other worms of its ilk infecting your storage network.
The Internet's nature is peer to peer - 20050301_cs_profs.pdf
SCSI may try to continue living, but it got only one direction to go: history's garbage pail.
You do realize that the serious data center hasn't run the SCSI protocol on a SCSI cable for years, right? We run FC everywhere. Even for our internal disks on some servers (Sun Vx80 series). Serial ATA doesn't even come close to SCSI over FC. My Hitachi 9570V gives me 19.5 TB raw storage and more than 100,000 IOPS. Let's see serial ATA and USB2 do that.
One more time, HyperSCSI, like FC and iSCSI is NOT for a desktop PC. It's for the data center. Although HyperSCSI provides some promise for extending centralized data storage to the desktop.
In my universe I'm perfectly normal, it's not my fault you don't live in my universe.
UDP is ideal for latency sensitive data, like real-time telemetry. It does require that you have excess bandwidth or control over who has access to the network if you want to avoid dropped packets.
Mea navis aericumbens anguillis abundat
USB maximum cable length: 5m
Serial ATA maximum cable length: 1m
Fiber Channel maximum cable length: 10,000 m
An therein lies your problem. You just can't get around the human error factor. People incorrectly install equipment and configuration mistakes abound in a corporate environment.
From excellent karma to terible karma with a single +5 funny post...
The lessons of NFS are being ignored, and I'd expect HyperSCSI to die when it hits the same limitations.
NFS started out UDP-based, and moved toward TCP with NFSv3. Why? Because having all that error correction done at the network layer made for a better product; TCP does all the work to insure packets aren't lost or out-of-order. UDP doesn't, and the NFS application layer had to handle it, making it slower, more painful, and a duplication of effort better spent elsewhere.
The industry guys are almost right on this one. It isn't a beer can with a motor; it's a beer can with an M-80. Fun to watch when it works right, damn painful if you screw it up.
How do SANS based on such things as HyperSCSI handle cuoncurrent filesystem accesses by mutiple different machines, since the device at the other end is just acting as a disk, and the host has to maintain filesystem integrity?
Saying that HyperSCSI is open source or HyperSCSI is under the GPL is pretty meaningless; those concepts don't apply to protocols. A HyperSCSI implementation is under the GPL, but so what? There are open source iSCSI implementations, too.
SATA is killing SCSI. Yeah. Thats right, I just replaced my 30 drive dual channel ultra320 array with... what, 3 12 channel SATA-150 controllers?
Come back and troll when SATA has doubled in speed, and when I can plug at least 15 drives into a card.
Or hell, just stay out of the game, since Fibre Channel has 2Gbit/ps (250MB/ps, still faster than SATA, slower than ultra320) and 255 devices, with multiple host access over a SAN, which can be set up redundantly. And that ignores the point of this article, SCSI over normal networking equipment.
So, to reiterate:
SATA - Lower speed. Lower capacity (# drives). Single host access. (Lower drive warranties too.) Cheap.
SCSI - Higher speed. Higher capacity (# drives). Multiple computer access via FC,iSCSI,HyperSCSI. (Longer drive warranties.) Expensive.
So, for the home user, cheap is good.
For the average financial institution which I'll estimate has roughly 1TB of information that needs to be available to everyone all of the time, well, they'll get what they pay for.
omgomg! You made me a FOE! I can't believe it!!!!!!!!! Some people have no heart here. :~(((
Forgive me while I go and cry my heart out..
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.
Come back and troll when SATA has doubled in speed, and when I can plug at least 15 drives into a card.
Hey, I plugged 15 SATA drives to my ass and had no problem with that at all. I don't know about you, but I ain't gonna try that with SCSI drives.
HyperSCSI, huh?
Well, let's just add that to SCSI, SCSI 2, Fast SCSI, Wide SCSI, Fast Wide SCSI, Narrow SCSI, Ultra SCSI (aka SCSI 3), Ultra-2 SCSI, Ultra-3 SCSI (Ultra-160 SCSI to some), Ultra-320 SCSI and iSCSI. (I'm sure I've missed something out.)
So what's next for this party? UberSCSI? 1337SCSI? TheOneRingSCSI?
"Accept that some days you are the pigeon, and some days you are the statue." - David Brent, Wernham Hogg
Fiber Channel maximum cable length: 10,000 m
Why would I want to store a HD so far away from my computer? If I want peripherals to communicate for such a distance, I'll just use LAN.
Your friend wasn't laughing at your CD burner, he was laughing at your incredibly tiny penis.
Don't you remember the last time we saw your mom naked, and you jizzed all over your usb HD? That was sick.
I hate to admit but you do got a point there.
(LOL!!)
"Why would I want to store a HD so far away from my computer?"
So you can keep your pr0n collection in your secret undergound bunker, along with your spare deflector beanies.
"If I want peripherals to communicate for such a distance, I'll just use LAN."
A LAN? That reaches ten klicks? Are we not clear on what the "L" in "LAN" stands for?
Never underestimate the bandwidth of a pair of sneakers carrying a hotswappable hard drive jogging down the hallway.
KFG
In looking for a cheap substitute for a FC SAN you don't need or want routing. You're looking a cheap way to implement a local, reliable, high performance fabric. That's all. People like iSCSI because it's compatible with existing infrastructure but they don't stop to think that they won't want to put their server farm storage on the routable corporate net. The problem with ethernet is that it's hard to scale performance with small packet sizes and all the buffering. Work is being done to fix that and it has nothing to do whether it's IP-based or not. Look at InfiniBand and iWarp for what's really important.
you generally prefer this unroutable
Off site backups?
Just because you cannot fathom a use for a particular technology does not mean that a technology is useless. Some companies find the ability to perform block I/O over long distances to be very useful.
It's not really applicable. You need a dedicated network with a high speed backbone, dedicated servers running a Unix to pimp the storage, and you'd be better off with a commercial clustering filesystem (GFS or some such).
;-)
I can see small offices, workgroups, and studios using this to get high-speed storage on line quickly with cheap components.
iSCSI has a better chance of being deployed in the home (of Unix-y types and their unsuspecting kin). I'd say, iSCSI all the way, none of this baby CIFS BS in my house!
Fuck Beta. Fuck Dice
The future if SCSI is SAS which is the SCSI protocol adapted to run over the serial ATA physical layer. Yes, traditional SCSI is having it's electrical layer replaced with the lowly one from serial ATA. Guess SATA is not so bad after all. FC is really exposed. It's expensive, poorly designed and is a poor performer. SAS, SATA, and InfiniBand are going to eat its lunch. I'm sure you've evaluated a lot of "serial ATA enclosures" too. Just what the hell is that since serial ATA is (currently) and internal attachment only?
When you want to duplicate a storage center offsite you want there to be a distinction between local and remote connections so that software can manage the syncronizing intelligently. Lots of protocols can run over fiber, not just FC, and connecting the two fabrics is not what you want to do. Once again, your argument for FC is specious.
You don't want to do off-site backups using block I/O unless you are stupid.
They are not the same, and increasing throughput doesn't necessarily increase latency.
Unroutable is definitely the way to go here.
You're gonna want to go with big packets and such. And you don't want to go through and entire stack just to get your sector.
Think of it this way, unroutable means never having to ARP.
Funny how the drive vendors don't agree with you. SATA is new. It's fast enough and has a roadmap to higher speeds. It's point-to-point design is a major strength over SCSI, you just do understand why. SATA is for inside the box. InfiniBand and iWarp are for outside. SCSI and FC are doomed to the scrap pile. Time is on SATA's side. You'll see.
And for some people the mechanical calculator will alway and forever be the only thing that should be deployed in engineering houses.
it's author is Jesse Keating
iSCSI has drivers for every OS you can imagine, written by CISCO, IBM, Microsoft, and released under the GPL. This is from the iscsi sourceforge page.
This implies for instance that one could boot ones diskless workstation from a collocated netapp on another continent, protected by a an IPsec tunnel. While i could do something similar with ethernet layer tunneled over IP, it leads to many complications and difficult debugging. I have personal experiance with this, as this how our company runs its ethernet layer phone system.
It stands for Storage Area Network. Here's a link courtesy of our overlords at Google.
Kill me if you like but Ethernet is NOT the right kind of media for this. Ethernet does not have "guranteed latency". It is not a real time thing--rather best effort thing. I will be happy to run this over a "fixed" latency media but not even think about doing it over ethernet. One of the reason I like firewire ... but I guess this is an apple thing and INTEL will do anything to kill it in the future or come up with other crap like USB.
- People who believe other people have no right to live, got no right to live ...
Actually I'm surprised there isn't FDM Ethernet. There's a lot you can squeeze down an enclosed wire. Just ask the cable TV guys.
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.
Hey, man, I use it for what it's meant to be used for.
I disagree with what you said; but moreover I disagree with how you said it. Basically, if you had instead tried to make some kind of a point instead of merely saying "* is dying!" (e.g., "BSD is dying!"), you might have at least avoided the Troll mod.
The foe designation is to mark you as someone who just doesn't get it and just doesn't care about that.
BTW, your sarcasm has been duly noted. Not that you care about that, either.
It is located here.
We recently built a 1.6 TB SATA file server for our (ahem) institution. Used a 3ware 8500-12 controller (which looks to the O/S like a single scsi device), 12 disks (10 active, 1 parity, 1 hot spare, 160 GB each). Redundant everything. The speed limiters turn out to be the filesystem (ext3, probably not the best choice for small files; writing directly to the device is about 60 MB/s, to the filesystem typically 10-20 MB/s) and the network connections. Our users haven't noticed a speed difference between it and the NetApp it replaced. But for about 1/10 the price, they sure noticed the 15x extra capacity!
Well, first off, "HyperSCSI' isnt such. All it is is just a correctionless protocol over ethernet hardware. Really, that's a bad idea. You'd be better off if you used ethernet hardware that sped up IPSEC and related ip protocols.
1: Create 2 networks, one being the normal network, and one being the SAN
2: Use GigE cable on your SAN with the inclusion of advanced Network FS'es like Coda.
3: Provide POP's that connect the external network with the internal SAN/serverNET by way of tunnels and port forwarding. Also offer a way to mount local share by Samba or the network FS'es you use internally. Kerberos and an LDAP would be a STRONG option for maintaining
Back in the day, we called that a "SneakerNet" network.
Forget thrust, drag, lift and weight. Airplanes fly because of money.
The GPL is not specific to Linux. You can have an application built upon Win32 and released under the GPL, and it will not run on Linux. The point of the GPL is not to help any particular operating system, yet to assist software to have a conditional freedom and authority backed by copyright law in recognition that if it were true public domain then it could be "hi-jacked" into another software.
The GPL establishes penalties for people or artificial entities that don't provide the sourcecode of the software, yet the GPL states it is voluntary to accept the GPL and if not accepted then copyright law is the premise for not accepting the GPL's distribution rules. And in copyright law, whoever using the copyrighted software needs the permission of the copyright owner on use of the alleged "software." GPL is a harmless fuzzball, fear the copyright owner.
If you want true freedom, then software would be released anonymously in the Public Domain and the risk is someone could steal the software and claim they own it. An example of a Public Domain work is the Authorized Version Bible aka King James Version Bible of 1611 A.D. All the recent alleged "Bibles" such as "New International Version", "American Standard", "New American Standard", "New King James Version" (false King James AV), and "Century New King James" (false King James AV), and many more are all actualy copyrighted! They are known as false Bibles because in their preface or inserts there is a text from a corporation that establishes conditions of their usage, unlike Public Domain bibles such as the King James Authorized Version Bible and also Gutenberg Bible. Further example, the NIV aka "New International Version" manifests conditions upon the reader: "The NIV text may be quoted and/or reprinted up to and inclusive of one thousand (1,000) verses without express written permission of the publisher, providing the verses quoted do not ammount to more than 50% of a complete book of the Bible nor do the verses quoted comprise more than 50% of the total work in hich they are quoted." In short, the NIV changes the many books of the Bible in such little ways to change the outlook and image of God's message and issues a copyright'd patent proclaiming they own and say how much you can quote without express permition! How long before a alleged "Bible" is released that says you can only read it on Sunday and only upon the permission and interpretation of an alleged "father of the Catholic Church" and you must accept the Catholic Church without condition as the divine authority of all scripture:
"For the Roman pontiff (pope), by reason of his office as VICAR OF CHRIST, and as pastor of the entire Church has full, supreme, and universal POWER over the whole Church, a power which he can always exercise UNHINDERED."
--CATECHISM OF THE CATHOLIC CHURCH, 1994, P. 254 #882
"[W]e hold upon this earth the place of God Almighty."
--POPE LEO XIII
"...We declare, state and define that it is absolutely necessary for the salvation of all human beings that they submit to the Roman Pontiff [pope]."
--POPE BONIFACE VIII, BULL UNUN SANCTUM, 1302
"No person shall preach without the permission of his Superior. All preachers shall explain the Gospel according to the Fathers. They shall not explain futurity or the times of Antichrist!"
--Pope Leo X, 1516
Although I may seem offtopic, my point I try to emphasize is copyrights are evil to the extent they can regulate and infringe upon others by use of truth and law that is vested in the mere essence of man if not written on paper. The GPL uses copyrights for the good of mankind, as if to turn copyrights into a double-edged sword, yet even the GPL can be used for evi
Secured Party, Without Prejudice, UCC 1-207: Creditor
Will you be able to boot from these devices? I don't see any mention of it in the article; I'd imagine you'd need support both in the BIOS and possibly the network card..?
Oh Lord and Master Jesus Christ, I pray you shine light upon this tortured living soul for he hath ommitted the many dimensions of the many flavors of SCSI... Single-Ended (SE), High-Voltage Differential (HVD), and Low-Voltage Diferential (LVD).
;-)
May we all be forgiven.
Secured Party, Without Prejudice, UCC 1-207: Creditor
but it's easier to write kernel code for linux, trust me. ::puts up hands:: All bets are off.
f they can't get that right...
Porting it to Solaris wouldn't fix it. You'd have the same issues, and a whole set of new ones.
Fuck Beta. Fuck Dice
Otherwise you might accidentally release a product that sucks as bad as NFS.
But seriously, NFS is only good for short haul networks. Over those networks, NFS/UDP is faster than NFS/TCP.
So what about long-haul networks? Answer: don't use NFS. NFS is FAR from secure. User management across administrator domains isn't handled either and therefore is all but impossible.
For what NFS is actually good at UDP usually fits the bill better than TCP.
And funny thing, I think you'll find this the case for internet SCSI too. You don't use a sector-by-sector remote block device protocol over long haul networks. It's horribly inefficient. Use a file-based sharing system instead.
I just think there's a horrible misunderstanding as to what this is good for. This is a block device protocol, not a file access protocol. That means that only one client can mount a drive (or technically range of blocks) at a time. A special case is multiple read-only mounters at once. But you have to bar any write access in that case.
So, if you have a protocol that is inefficient over long-latency links regardless of transport and requires a 1:1 match of volumes to users, why do you care whether it works well from cross country?
While UDP clearly was the wrong choice, TCP isn't the right choice either: TCP is a reliable, connection-oriented stream protocol. But for file and device access, you want a reliable connectionless protocol.
There are a number of choices. Plan 9 defined IL for just this purpose, there is SCTP for telephony applications, and several operating systems support RDM ("reliably delivered message"). Maybe people should just start using one of them, rather than reinventing the wheel by building on top of unreliable datagrams or by using protocols with unnecessary overhead.
Borg SCSI: Your hard drive will be assimilated into the Borg SAN.
Anybody got one for SovietRussiaSCSI? (I just woke up...)
NataliePortmanSCSI?
I, for one, welcome my new SCSI overlords!
Regarding this, I really appreciate how you explain me why you're my foe.
And it's understood. "Pervertus" deserves no friends. I just write what's on my mind with almost no filtering whatsoever. And that exact moment I was angry on SCSI (and on big flat cables). And if you look on my journal, you'll see what a nasty entity I am! But still I wish someone would have been my friend....
Add the appropriate routers and switches and you can easily go 90 km on dark fiber.
It's not going to be dark fibre if you're using it, is it??
HP's Graham Smith says:
"Without TCP/IP, it has no real error-recovery mechanism or guarantee that packets get delivered."
But that is wrong. There is error checking in the ethernet hardware and in the SCSI stack. It seems Smith needs to review the basic material, or should have at least read the introductory material. Perhaps the takeaway here is, managers should not be allowed to comment on technical material, or if they do, they should solicit advice from a practicing engineer first.
Smith also dumps on HyperSCSI's scalability, but as far as I can see, it scales exactly as well as any LAN, and for storage that's not bad at all. Besides, being 100% open source, implementing a repeater sitting on a routing box is entirely practical.
As far as Andre's comments go, the article should have disclosed that he peddles an iSCSI stack for a living. More power to him, I'm not criticizing his colorful comments or business scheme, just the journalist's failure to take note of this.
Now, my own opinion: I haven't tried HyperSCSI yet. I have it installed here and by rights I should have given it a thorough workout by now, but mea culpa. So little time, so much to do. Well I'll change that today.
From what I know so far: I like the idea of trimming away unnecessary layers. It's the kind of thing we do in Linux all the time. I like the fact that the whole stack is GPL. It doesn't bother me that disk drives themselves don't support the protocol and are unlikely to in the near future, because you have to put the disks in a box anyway, and that might as well be a Linux box presenting a HyperSCSI interface.
Personally, I think that HyperSCSI is going somewhere. So is iSCSI for that matter: the two protocols serve distinctly different target markets. iSCSI is where the money is because hardware vendors support it. HyperSCSI is where the joy of hacking is because it performs better and it's GPL. The thing is, they both present the same interface to the OS (SCSI) so they are interchangable. It's not an either/or situation at all.
You need to pay careful attention to any technique that increases performance without increasing cost.
Have you got your LWN subscription yet?
I think if you read again, and this time don't assume every poster above you doesn't already know this, you'll see the point they were trying to make.
If this uses it's own Layer 3 protocol (presumably, and for the sake of argument, called HyperSCSI), then it's NOT IP BASED... and the article summary indicated it was IP based, then contradicted itself.
When someone says "TCP/IP" they are referring not to a protocol, but a protocol suite. They are NOT referring to "TCP and UDP ONLY".
So, if you say something is not based on tcp/ip,that indeed DOES mean it does not use IP. Furthermore, saying it uses "raw ethernet" indicates that this uses it's own layer 3 protocol, other than IP.
When someone says "TCP/IP" they are referring to the entire protocol suite, which involves TCP, UDP, ICMP, and other stuff on top of IP.
It does not at all mean that they are using TCP itself.
There is a possibility that you would have a small number of machines in a clustered configuration that are serving a database or other disk intensive task, and who share a large, distributed volume.
:-)
Since HyperSCSI is supposed to help you save money by enabling cheap hardware utility, I'd expect the flexibility to realize something like that to maximize the utility of connection-rich 1U/blade servers available today.
Also, don't you think it might be useful that a member of the disk array could access the whole volume to do maintenance tasks or check for consistency? This could be quite useful for a vendor who wishes to sell self-contained NAS solutions.
And re: the SCSI/FC disconnect property... ethernet protocols are generally disconnect tolerant. I'm not saying HyperSCSI has to have that property (mostly because SCSI protocols don't allow for it), but that doesn't mean the HyperSCSI client driver should cause the system to crash. It shouldn't assume the transport layer is reliable, and there are ways to sense link state, so why not protect the user from failure? Scream at syslog, maybe the sysop will get an email, and could plug it in, umount, save the cluster, save the day.
I can only dream.
Fuck Beta. Fuck Dice
solaris would not tolerate shoddily written re-entrant kernel code. I guarantee a crash so hard you can hear it.
;-)
What was that? Did someone hit my car?!
Oh wait, my Blade just froze up, hmmm...
Some of the SMP-tolerant kernel code in linux gets by on the good graces of the IO-APIC keeping interrupts from coming in too fast... heh. heh.
*cough*
Fuck Beta. Fuck Dice
Absolutely right, except for teh monitor... Firewire actually IS fast enough to supply data to your monitor.
But even better, is the fact that you could have an unlimited number of drives, either inside or outside of your case (it really wouldn't matter... All drives would be portable, external drives)
Not only that, but firewire is already less expensive. Combining all these purposes would make firewire more popular, and hence, even less expensive.
Yeah, and then there's the fact that firewire is already supported by most everything, is hot-swapable, and you wouldn't have to worry about jumper settings again.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Firewire has enough bandwidth to run a display, but the signal still has to come from a dedicated video card, and displays would have to support it, there's really no motivation there. Better to have a DVI out with an adapter for HD15 analog RGB VGA and above.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
"IP-like" is not "IP"
if it doesn't use IP, it doesn't work "over IP". Either it's IP, or it is not.
By the way, HyperSCSI is a layer 3 protocol, and it has absolutely nothing to do with IP.
The article summary was mixing up iSCSI (which runs over IP only, using TCP) and HyperSCSI (which is it's own protocol)
Maybe you could mod your fibre transcievers with some l33t "dark light" UV lasers. Woot.
Yeah, and then there's the fact that firewire is already supported by most everything, is hot-swapable, and you wouldn't have to worry about jumper settings again.
Yeah, and then there's the fact that it'll be a cold day in hell when 'they' start building their primary IO around an Apple-invented technology.
Ignoring for now the similarities between AppleTalk and USB, NuBus and plug-n-play PCI, integrated sound chips on every motherboard, etc. Gee, looks like they'll have to come up with SerialATA version 3 that does everything that Firewire does, but slightly differently, first. Next thing you know there'll be forth drivers on PCI cards. Sheesh.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)