Slashdot Mirror


"iSCSI killer" Native in Linux

jar writes "First came Fibre Channel, then iSCSI. Now, for the increasingly popular idea of using a network to connect storage to servers, there's a third option called ATA over Ethernet (AoE). Upstart Linux developer and kernel contributor Coraid could use AoE shake up networked storage with a significantly less expensive way to do storage -- under $1 per Gigabyte. Linux Journal also has a full description of how AoE works." Note that the LJ article is from last year; the news story is more recent.

235 comments

  1. AOE? by laffer1 · · Score: 5, Funny

    I didn't know Age of Empires can do network storage! WTG Microsoft!

    1. Re:AOE? by AviLazar · · Score: 0, Offtopic

      No, not age of empires n00b, Area of Effect. This guy is clearly a mage or a warlock (maybe a priest or paladin). If a warlock, I wonder if he likes to use Rain of Fire or Hellfire.

      --

      I mod down so you can mod up. Your welcome.
    2. Re:AOE? by metasecure · · Score: 0, Offtopic

      n00b a fireball is a single target attack !

      they're talking about frost nova or blizzard etc !

    3. Re:AOE? by gEvil+(beta) · · Score: 0, Offtopic

      I didn't know Fireballs could do network storage!

      Fireballs have been able to do network storage for at least a decade...

      --
      This guy's the limit!
    4. Re:AOE? by Mayhem178 · · Score: 0, Offtopic

      .....and you're wrong on 2 accounts. First off, I wasn't talking about Diablo. WotC = Wizard of the Coast = D&D. And secondly, Diablo's Fireball DOES do AoE damage, just not in a very big radius.

      n00b!!!! :)

      --

      "You will pay for your lack of vision..." - Emperor Palpatine to Ray Charles

    5. Re:AOE? by laffer1 · · Score: 0, Offtopic

      Age of Empires predates World of Warcraft. I do play both and I have a mage. :)

    6. Re:AOE? by Mayhem178 · · Score: 0, Offtopic

      Heh...you know, I wasn't even thinking about that when I posted the comment. Touche!

      --

      "You will pay for your lack of vision..." - Emperor Palpatine to Ray Charles

    7. Re:AOE? by AviLazar · · Score: 0, Offtopic

      Age of Empires is still one of my favorite games. Probably because I would go to a friends HS classroom (after school hours) with a bunch of friends and we would play maxed out games (I think 5 to a team, I forget the limits). It was a lot of fun as players would shout over to each other "No do this do this you n00b. Stupid morons" and someone else "Type it out!!! They can hear your plans when you shout!!!". It was a lot of fun with pizza, soda, and good friends.

      --

      I mod down so you can mod up. Your welcome.
    8. Re:AOE? by utopianfiat · · Score: 1

      I'm sure there are Blizzards with their own network storage, but I don't know about Frost Nova...

      --
      +5, Truth
    9. Re:AOE? by Gattman01 · · Score: 2, Funny
      a fireball is a single target attack!


      I'm sure that'll go over great with your party fighting enemies in a narrow hallway.
      I'm sure the DM and your party members will be VERY forgiving when they have to create new characters.


      I forget, the AoE of Fireball is either 5 feet or 5 meters. Either way, using it in a small room is not a good idea when you're in the room, unless you don't like your "friends."
    10. Re:AOE? by NitroWolf · · Score: 0, Offtopic

      Damn, the n00b count is high!

      Fireball (and any AE spell) does not do AoE damage, they do AE damage. AoE is the resulting radius of an AE spell. A spell can't be AoE, it can only be AE. There's no such thing as an AoE spell, only AE spells.

      Only n00bs say AoE spell. Vetrans know it's AE.

      The same goes for military weapons - You don't say "Our Area of Effect warheads in the MLRS were ineffective."

      You say "Our Area Effect warheads in the MLRS were in effective, as the Area of Effect was too small."

      Duh.

    11. Re:AOE? by nine-times · · Score: 1

      n00b? Am I the only person for whom "AOE" means "Aces Over Europe"

    12. Re:AOE? by Smelecat · · Score: 2, Funny

      Use AoE with caution. In a crowded data center, AoE will agro nearby equipment.

    13. Re:AOE? by Da_Weasel · · Score: 1
      Damn, the n00b count is high!

      It's a meer drop in the bucket compared to the virgin count!
      --
      If you must!
    14. Re:AOE? by AlgorithMan · · Score: 1

      no no no no NO! you got it all wrong... the only connection this has to microsoft is this: microsoft will wait if it gets popular - and if it does, they sue Coraid, because they infringe microsofts copyright to age of empires - then they'll forbit it's implementation on unix systems and sell it as their own idea...

      Microsoft AoE server enterprise 2007 - $200 per year - anyone interested?
      I should shut up or I'll get in trouble with the genuine advantage team...

      --
      The MAFIAA is a bunch of mindless jerks who will be the first up against the wall when the revolution comes
    15. Re:AOE? by generationxyu · · Score: 0, Offtopic
      Uh, if you're depending on a warlock, priest (lol, holy nova?) or paladin (???) for an AE encounter, you've really got problems. Warlock's job in a raid -- CoA (or CoE to help your mages), other DoTs, shadowbolt, blood pact, SS a rezzer in case of wipe. Priest's job -- heal. When you're done healing, heal more. If you need a break, heal. Oh, and once in a while you might want to heal. You do DPS while you're /oom with your wand. Paladin's job in a raid -- melee DPS, off-healing, off-tanking. If you're talking PvP, locks should be fearing/dotting/charming everything in sight, priests should be healing unless it's 1v1, paladins should be generally an annoyance to both sides (horde hates them cause they're hard to kill, alliance hates them because they won't realize that the best thing they can do in PvP is heal other people who can actually do/take damage) Leave AE for a class that's designed for it -- and the only class that's designed for it is mages. Of course, if you've got a big AE encounter, like the hallway in AQ40, the locks might as well help, as I guess the marks hunters should too, but the mage is by far the most efficient AE class -- lots of mana, lots of mana efficiency, 2 good ranged AEs, 2 good close range AEs, plus FN to keep them in line. And a frost mage is using 15% less mana and generating 30% less threat on his Blizzard, which is also giving the mobs a chill debuff which has a 15% chance to freeze, which gives him an extra 50% crit chance. Mages == AE pwnage.

      * nerf locks

      --
      I mod down pyramid schemes in sigs.
    16. Re:AOE? by AviLazar · · Score: 0, Offtopic

      Ok if I was raid leader and the first thing my warlock did was CoA over CoS he would be told to fix his mistake. If he would argue, he would be raiding with another guild. CoA? Pfft. CoA ONLY comes out by the third+ warlock in the group...and depending on the mob, the third warlock might be doing CoT.
      Dots are always the obvious. And if you think warlocks can't outdamage mages in AOE you are mistaken. I consistantly out damage my mages. Try Nefarian's minions before he lands...I am there with Rain of Fire. Actually, the guild likes to have us locks stand in the middle and do hellfire while priests bubble/heal us.

      As a destro lock my character is consistantly doing searing pain (except very few bosses) and doing massive crits. Two nights ago, yea magmadar, three crits in a row for 1000+ with searing pain.

      In PvP. It is CoA (unless you are partied with a mage, which my best friend is one, which then I do CoE), Corrupt, Immolate, Searing pain, Conflag, searing pain ---oops my target died. Fel puppy all the way. Fear only when I am 1vs1 or can find a good hiding spot.

      When the Naxx world event was going on the most powerful combo would be to have a warrior ride around his horse...aggro 30+ mobs, and then the priest would stand in the middle aoeing them to death. It was beautiful. Only reason priests needed the rest of us was for the end boss.

      To say Warlocks aren't designed for AE is wrong...the only time warlocks complain about their AE is in pvp cause it's channel based. In case you didn't know, warlocks have two different talents geared for AOE.

      Warlocks have more mana then mages - lifetap, healthstone, lifetap, potion, lifetap, bandages, lifetap, etc.

      Mages have better on the ranged attacks with their 41' attacks.

      Frost mages don't do as much damage as lock aoe.

      Nerf locks? Pfft, buff locks. After DC (which is the only complaint people have about locks) they got nothing in defense. DC being on 2 minute cooldown is not game breaking.

      *nerf Shammies

      --

      I mod down so you can mod up. Your welcome.
  2. Will it catch on? by andrewman327 · · Score: 4, Insightful
    From TFA:
    Some significant caveats mean that not everyone is so keen on the technology. For a start, it's a specification from Coraid, not an industry standard. Its networking abilities are limited. And its detractors include storage heavyweights such as Hewlett-Packard and Network Appliance.


    So will this ever develop into a real standard or will it remain the sole domain of one company? I do not know if I want to invest time and money into it if the latter is true. From a comp sci point of view this is a great approach to networked storage. It uses what people already have to make storage reletively cheap. I am going to wait to see where this technology goes. Maybe it will blossom and become a serious contender.

    --
    Information wants a fueled airplane waiting at the hangar and no one gets hurt.
    1. Re:Will it catch on? by Anonymous Coward · · Score: 1, Informative

      iSCSI is routable and secure if you use an encrypted tunnel (ipsec native in most implemenations) whereas AoE is local network only and non routable.

    2. Re:Will it catch on? by SpecTheIntro · · Score: 3, Informative
      For a start, it's a specification from Coraid, not an industry standard.

      I don't know that this is true, because the LinuxJournal article directly contradicts it. (Unless I'm misreading it.) Here's what the LJ says:

      ATA over Ethernet is a network protocol registered with the IEEE as Ethernet protocol 0x88a2.

      So, it looks like the protocol has been officially registered and was granted approval by the IEEE--so that makes it an industry standard. It may not be adopted yet, but it's certainly not something like 802.11 pre-n or anything; there's an official and approved protocol.

    3. Re:Will it catch on? by hpa · · Score: 4, Informative
      So, it looks like the protocol has been officially registered and was granted approval by the IEEE--so that makes it an industry standard. It may not be adopted yet, but it's certainly not something like 802.11 pre-n or anything; there's an official and approved protocol.

      Anyone can register a protocol number with IEEE by paying a $1000 fee. It doesn't mean it's a protocol endorsed by IEEE in any shape, way or form.

    4. Re:Will it catch on? by Jeff+DeMaagd · · Score: 1

      If it develops into a standard, it would appear that maybe it will have a niche. It sounds like a nice idea that may be worth a shot for some uses. I can't help but wonder if the higher cost of iSCSI and FiberChannel is there for a necessary reason. The nice thing though is that even desktop systems are being made available with multiple network adapters, so one can be dedicated to this sort of storage.

    5. Re:Will it catch on? by andykuan · · Score: 1

      The lack of routing doesn't really bother me so much though. Do I really want to send raw drive data through my router? I figure I can use this to build a low-cost NFS cluster -- but instead of having to invest in a dedicated SAN or a differential SCSI bus, I can just share drives over my existing Ethernet switch.

    6. Re:Will it catch on? by dfghjk · · Score: 1

      considering that it's non-routable, in what way is this "a great approach to networked storage"? Ethernet simply takes the place of a SCSI cable here and the device protocols differ. It lacks some of the availability characteristiccs of SATA/SAS and fails to solve and sharability issues because it's still a block interface. "From a comp sci point of view" it's a total dud.

      The problem with ethernet is that it's hard to make go fast. We have 1G now but 10G is difficult because of all the processing involved and the offload engines that come with that. IF I could read the article perhaps I might understand if this is better in that respect, but the future of networked storage does not lie in block device protocols. To make this interesting we need 10G links and file symantics.

    7. Re:Will it catch on? by SpecTheIntro · · Score: 1

      So then what qualifies as an "industry standard?" Is that just a euphemism for: "the big players have decided to implement this technology?"

    8. Re:Will it catch on? by magetoo · · Score: 1
      The problem with ethernet is that it's hard to make go fast. We have 1G now but 10G is difficult because of all the processing involved and the offload engines that come with that.
      The offload engines do TCP, don't they? And since this thing goes directly to raw Ethernet ... or would it still be a problem?
    9. Re:Will it catch on? by dfghjk · · Score: 1

      I was just saying that I hadn't read the article since it's unavailable. I would assume that the problems with performance under 10GigE don't apply because TCP isn't used. I would also assume that the offload engines can't be taken advantage of with this protocol.

      I could see benefit in using this over iSCSI for 10G NIC's without TOE's but I wonder if there will be any of those. There real advantage of running anything over ethernet is to get the benefit of huge volumes, so I would suspect all 10G Nics will have TOE's.

    10. Re:Will it catch on? by brainnolo · · Score: 1

      Yes, exactly.

    11. Re:Will it catch on? by Harik · · Score: 2, Informative

      The non-routable is a killer. Protocol-level bridging, no off-site redundancy, strict dependancies on port location. No thanks, it's a toy protocol that may get some use in the home NAS market, but it was hell to implement a reliable setup in our lab under controlled conditions. I'd hate to have to deploy it 'for real'.

      The only way to really do it is to purchase a dedicated Block Controller (spare ethernet card) and a dedicated Block Data Cable (Cat 5) and hook it up to a dedicated Block Device Multiplexer (switch). If you want a replacement for FibreChannel and are willing to live with the limits of direct local physical connections, it's useful.

      Just have fun getting those frames into a xen/vmware virtual host from an external machine...

    12. Re:Will it catch on? by Tracy+Reed · · Score: 1

      I don't know if the RFC has been ratified but the AoE spec if definitely freely available from coraid's site. It is 8 pages long compared to iSCSI's 257 which I really like. There are open source implementations of AoE targets and initiators. It is not the domain of one company and can never be. As far as I am concerned it is already a serious contender.

    13. Re:Will it catch on? by andrewman327 · · Score: 1

      I would like to see other vendors (preferably larger industry bellwethers) carrying the technology before I consider it a serious contender.

      --
      Information wants a fueled airplane waiting at the hangar and no one gets hurt.
    14. Re:Will it catch on? by dfghjk · · Score: 1

      The dedicated controller and switch are exactly what it's intended for. Anything else is foolish. Servers SHOULD connect to their storage that way, not through a shared network.

      Since when do you do offsite redundancy that way? Your link to the offsite location is slow relative to your local connection and you want your software to know that.

      No way is AoE intended for the home NAS market (it isn't even NAS) but it may eventually find a use there.

    15. Re:Will it catch on? by Anonymous Coward · · Score: 1, Funny

      > Anyone can register a protocol number with IEEE by paying a $1000 fee. It doesn't mean it's a protocol endorsed by IEEE in any shape, way or form.

      Hmmm, damn. Of course, I wonder how many people would think it was endorsed by the IEEE, anyhow?

      Makes me with I had $2000 to throw around for the new "SenStevensTube" and "BigTruck" protocols ...

    16. Re:Will it catch on? by booch · · Score: 1

      Most people would PREFER a non-routable protocol for SAN traffic. Generally, the best design is to segregate your SAN traffic from all other traffic, on a separate segment. Just like you'd be best to have your SQL traffic going over a different network than your web traffic. Mostly for performance reasons, but also for security reasons. You don't want your raw data crossing networks that you don't have tight control over. Using a non-routable protocol ENSURES that your traffic stays where you want it.

      I fail to understand your last 2 paragraphs. Using an Ethernet NIC, switch, and cables is pretty much how the whole thing works. What were you expecting? As far as virtualization, I'm pretty sure that most VMs use bridging -- not routing -- to multiplex the NIC, so I still don't see any issue.

      --
      Software sucks. Open Source sucks less.
    17. Re:Will it catch on? by Anonymous Coward · · Score: 0

      Too bad that TCP wasn't the ISO standard it might have caught on instead of the OSI Stack.

    18. Re:Will it catch on? by Anonymous Coward · · Score: 0

      No, it means that many large organisations have conspired to cripple an elegant solution in order to better make it fit within their respective business models.

    19. Re:Will it catch on? by sjames · · Score: 1

      It's not DIRECTLY routable, and that's a GOOD thing. TCP/IP has an overhead associated with it that is quite wasteful if source and target are on the same subnet. If they are not, it makes perfect sense to then (and only then) encapsulate AoE inside bare IP or even UDP. That way you only pay the overhead where it is necessary.

      It is also possible to set up a dedicated private connection to a remote location with a bridged connection. MOST situations where the attached storage is remote, you wouldn't want to route over the public internet anyway (especially without good crypto).

      Given that, the IP overhead of iSCSI looks like a complete waste that drives up cost and complexity for no good reason.

      Notably, the Linux Network Block Device predated all of this by several years. The only missing part was drives that directly implemented the server side rather than needing to be connected to an embedded Linux device.

  3. Another "Killer" by slimjim8094 · · Score: 1

    Why does it seem like everything open-source is a proprietary "killer"?

    Having said that, this looks pretty neat. It will probably be more widely accepted, being open source (it is, right?), so it can be ported easily. Features will grow quickly, and other OSS advantages and so forth.

    However, why is this better than NFS or Samba/Windows shares? Is it faster? It seems like AoE is offloading more of the low-level stuff to the client. Is this a good thing? It doesn't seem like one...

    --
    I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
    1. Re:Another "Killer" by wasabii · · Score: 4, Informative

      AoE is a networked block device technology. NFS and Samba are network file system. One is about making block level access to a device available over the network, the other is about making file operations available.

      In the case of AoE, a single remote block device can be shared between multiple systems. Each client could issue it's own write/reads. in combination with a distributed file system, each node could mount the same FS.

      It's the same as NBD, iSCSI, Shared SCSI, and Fiber Channel.

    2. Re:Another "Killer" by die444die · · Score: 1
      Having said that, this looks pretty neat. It will probably be more widely accepted, being open source (it is, right?), so it can be ported easily.
      Yeah, just like OGG took off because it was open source. Hah.
      --
      die444die
    3. Re:Another "Killer" by slimjim8094 · · Score: 2, Insightful

      So was MP3 (at least implementations) and it was around longer and more widely supported by programs/devices.

      --
      I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
    4. Re:Another "Killer" by Anonymous Coward · · Score: 0

      It's Fibre Channel, not Fiber Channel. Good post, though.

    5. Re:Another "Killer" by Anonymous Coward · · Score: 1, Insightful

      "Yeah, just like OGG took off because it was open source. Hah."

      It won't take off anytime soon because Microsoft and Apple's native players do not support it (why not?). If they did, it would help. Imagine not needing anybody's special plugin. MS/Apple just want you to use their media files and don't care what a hassles it creates for the user in the mixed environment of the internet.

    6. Re:Another "Killer" by GoRK · · Score: 1
      It's the same as NBD, iSCSI, Shared SCSI, and Fiber Channel.


      I suppose you mean Fibre Channel, and no, AoE not the same as any one of these technologies, though it is more like iSCSI than the others. Yes, you can do similar things with all of these, but they all have various advantages, disadvantages, and unique capabilities in comparison to each other.

      Sadly, AoE while pretty cool technology is probably not going to last much longer when SAS and iSCSI really start getting together. A SAS Expander with a built in iSCSI bridge would be a fairly uncomplicated (hopefully inexpensive too) device and would have the benefit of being fully compatible with SATA targets (drives).
    7. Re:Another "Killer" by Anonymous Coward · · Score: 0

      What I'd like to see instead is high quality native Linux support for iSCSI targets. You can patch the kernel now, and do this today, but you won't approach the performance of the proprietary solutions. Linux can and should commoditize iSCSI, just as it has commoditized other infrastructure components.

    8. Re:Another "Killer" by die444die · · Score: 2, Informative

      My point was that something being opensource does not really help it in the end. In fact, this seems to rarely boost public appreciation of any product.

      --
      die444die
  4. Cheaper? by DSW-128 · · Score: 4, Interesting

    I guess I don't really see how it's cheaper that iSCSI? Sure, there's less overhead from the lack of TCP/IP, so you may not need as massive a network to drive it equally. But I've been under the understanding that iSCSI doesn't require SCSI drives, so you could build an iSCSI target out of the same machine/drives as an AoE host, correct? For some applications, I think the lack of TCP/IP might be a benefit - less opportunity to hack. (Then again, I'd expect anybody deploying something like this or iSCSI would drop the few extra $$$ to build a parallel network that transports just storage.)

    --
    This .sig is printed on 100% recycled electrons, but is best viewed using 100% fresh photons.
    1. Re:Cheaper? by hpa · · Score: 2, Informative
      The main advantage of AoE is that it's simple enough that you could build it in hardwired silicon if you wanted to, or use small microcontrollers way smaller than what you'd need to run a fullblown TCP stack (this is what Coraid does, I believe.)


      The main disadvantage with AoE is that it's hideously sensitive to network latency, due to the limited payload size.

    2. Re:Cheaper? by NSIM · · Score: 2, Informative

      You are quite correct, there is no requirement for SCSI drives in an iSCSI implementation, iSCSI refers the protocol, not the drive interface, i.e. it's the SCSI command protocol implemented over TCP/IP. So yes, you can build an iSCSI system out of commodity parts and many people are doing so. if you want get an idea of the options out there for doing this, take a look at: http://www.byteandswitch.com/document.asp?doc_id=9 6342&WT.svl=spipemag2_1

    3. Re:Cheaper? by tylernt · · Score: 1
      But I've been under the understanding that iSCSI doesn't require SCSI drives
      Correct, I built a Windows 2003 Cluster (just for testing, not a production system!) using a Linux iSCSI target on an IDE drive and the stock iSCSI initiators on the 2003 boxes. Performance wasn't great but it worked fine.

      With Copper Gigabit Ethernet and Jumbo frames (standard Ethernet is 1500 bytes, but disk blocks are usually 4K so you uneed Jumbo frames to eliminate fragmentation), I'd think you would save a lot of money over Fibre Channel and only take a small hit on performance.
      --
      DRM 'manages access' in the same way that a prison 'manages freedom'
    4. Re:Cheaper? by rf0 · · Score: 1

      I've got an iSCSI setup using http://www.open-e.com/ (basically a custom debian distro on a compact flash) hooked upto a 3Ware 9550SX with Western Digital RAID disks (all SATA). So the short answer is you can just use normal disks. If you really want it on the cheap you can do a single system with a single disk, although why you would want to I don't know

    5. Re:Cheaper? by tbuskey · · Score: 2, Informative

      I hacked together an iSCSI setup from some old hardware.

      2 P II 400MHz systems running FC4
      One system had software raid 0 on 2 IDE drives.
      The target has a spare 10GB IDE drive.

      Added 2 10/100T cards with a crossover cable.

      Did a quick dd if=/dev/zero count=some large number of=the raid mirror or iSCSI target.

      The iSCSI target was 30% slower.
      Way cool.

    6. Re:Cheaper? by Dadoo · · Score: 1

      there's less overhead from the lack of TCP/IP

      If that's what they're after, why not use HyperSCSI?

              http://en.wikipedia.org/wiki/HyperSCSI

      --
      Sit, Ubuntu, sit. Good dog.
    7. Re:Cheaper? by Zephiris · · Score: 3, Insightful

      The really silly thing about this is that they claim it's "lower overhead" than TCP/IP because people are having to buy "expensive TCP offloading engines" for iSCSI, when a few seconds of research provided, namely on Wikipedia (http://en.wikipedia.org/wiki/ISCSI), that plain NICs can outperform the offloading ones, and sure, it's obviously going to be lighter than TCP/IP, however, ATA over Ethernet only has basic authentication (MAC addresses, which can be forged cheerily), can't be routed, and isn't very available. It's -only- usable for Storage Area Network, not really for general remote drive (or part of a drive even) access. At currently, only Linux support is available. iSCSI is supported by Windows, Linux, Solaris, among others. Even FreeBSD is working on a native implementation. Windows Vista will even include a fully built-in/native support for iSCSI. I can't imagine why they complain that iSCSI is 'more expensive' to implement, when their primary product for ATA over Ethernet is a 'special drive enclosure' (according to their documentation, you can't even use AoE with standard networking hardware, interfaces, routers, etc) with special networking hardware which can house up to 15 ATA drives. The enclosure itself (with nothing else) costs about $4000. You could build ten high-end machines dedicated to serving iSCSI requests to multiple drives each for that (five if they use actual SCSI), and still use standard networking hardware, and still have it accessable from a network across the world, with things like actual user authentication.

      The whole ATA over Ethernet thing seems like trying to blow smoke up the arses of some very rich and silly people. At the same time, the technologies are rather different, too. If you just want to build a SAN? Sure, go for HyperSCSI or AoE, maybe, but if you actually want remote drive access? Why would you want any of this? They shouldn't be trying to utterly replace iSCSI. It's absurd. As far as I see it, iSCSI is more of a general and free/open replacement for things such the old 'X drive' remote service, and network filesharing like SMB/NFS. Websites can (and are starting to) offer iSCSI targets to offer remote drives for backup. It can also be used for cheap SAN, or more-or-less replacing SMB/NFS over a network. It does all of this rather well.

      It seems to me that the company behind ATA over Ethernet is becoming rather desperate to resort to such claims.

      --

      "A Goddess rarely smiles for she is forced by others to be an island unto herself." - Zephiris
    8. Re:Cheaper? by blackjackshellac · · Score: 1

      Gige is imperative for any decent network performance, but it's pretty cheap these days, so it's not a huge issue. I wouldn't bother with setting up jumbo frames since you always end up with alignment issues with the iscsi headers + data. And yes, I've been able to easily keep up with most FC hardware, with only sata drives on the backend. I've seen anywhere from 100MB/s (800Mb/s) to 118 MB/s (944 Mb/s) with a couple of fast sata drives on the target, and raided iscsi devices on the initiator (client). And those throughputs are sustained, not bursts.

      --
      Salut,

      Jacques

    9. Re:Cheaper? by Anonymous Coward · · Score: 0

      iSCSI requires a SAN. SAN = Very expensive equipment. AoE does not require a SAN.

  5. More for business? by gasmonso · · Score: 1

    Not sure if I follow this. Harddrives are well under $1/GB. If you buy several 400 GB drives and just connect them in an old PC thats on the network, aren't you accomplishing the same thing? I have a terraserver at home and it cost http://religiousfreaks.com/

    1. Re:More for business? by HaloZero · · Score: 1

      If you had to commit ritual sacrifice of several religious zealots in order to pay for your Terraserver, then you may have spent too much on it.

      --
      Informatus Technologicus
    2. Re:More for business? by jimicus · · Score: 2, Informative

      Maybe cheapie little IDE hard disks are under $1/GB. If you want hot-swap, availability of half-decent RAID cards and disks which actually get to see some testing before they leave the factory, then you'll have to spend quite a bit more.

    3. Re:More for business? by riley · · Score: 2, Interesting

      Storage Area Network solutions are not under the $1/GB. Running a network filesystem (NFS, SMB, Coda, etc) are running a local filesystem over networked storage are two different things, fulfilling two different needs.

      iSCSI and AoE don't necessary directly benefit the small/home server market, but for the things that SANs are traditionally used for (data replication across geographically separated sites without any changes to the application software) there could end up being a big win in cost.

    4. Re:More for business? by bhima · · Score: 1

      I don't know... in some parts around they're really common... so they must be cheap.

      --
      Nothing in the world is more dangerous than sincere ignorance and conscientious stupidity.
    5. Re:More for business? by Anonymous Coward · · Score: 0
      availability of half-decent RAID cards
      That isn't a serious feature. Nobody with half a brain still uses RAID cards. Software RAID is the way to go. You telling me that some little 8-bit microcontroller can XOR bytes faster than an already-underused Opteron CPU? Or for that matter, faster than the cheapest Celeron ever made?
    6. Re:More for business? by rf0 · · Score: 2, Interesting

      iSCSI is slightly differnet as rather than presenting a file system, it presents a hardware device. So you show it a 1TB device over the network (e.g /dev/sdb) then the client machine can partition that disk up as if it was local. Thats the advantage over just a shared network filesystem

    7. Re:More for business? by afidel · · Score: 1

      There's this thing called batter backed write cache, you might want to look into it. Without it you either have horrible write performance or a serious consistancy problem.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    8. Re:More for business? by labratuk · · Score: 0, Redundant
      If you buy several 400 GB drives and just connect them in an old PC thats on the network, aren't you accomplishing the same thing?

      But do you get drive hotswap and near infinite expandability from that?
      --
      Malike Bamiyi wanted my assistance.
  6. Reliability by Neil+Watson · · Score: 1, Interesting

    People often forget there is a considerable difference in the reliability of ATA drives versus SCSI. If you are going to use some sort of ATA based SAN be prepared for disk failures much sooner than if they were SCSI.

    1. Re:Reliability by dfghjk · · Score: 2, Insightful

      how is that relevant to the discussion of protocols?

      reliability of SCSI versus ATA is largely imagined and the rest is intentional. drive manufacturers want you to believe their enterprise drives are more reliable and right now those drives are largely SCSI.

    2. Re:Reliability by SpecTheIntro · · Score: 3, Informative
      People often forget there is a considerable difference in the reliability of ATA drives versus SCSI. If you are going to use some sort of ATA based SAN be prepared for disk failures much sooner than if they were SCSI.

      This is not necessarily true. It all depends on how your network storage is being used. SCSI drives are built and firmware'd for the sole purpose of running a server, and they consistently beat any ATA drive (be it IDE or Serial) when it comes to server performance and reliability. ATA drives just aren't built to handle the sort of usage a server requires--note that this isn't a reflection of quality, but of purpose. But a file server (which is the only thing the SAN would be used for) requires much less robust firmware than a server housing MySQL, PHP, maybe a CRM suite, e-mail server, etc.--and so ATA drives shouldn't immediately be ruled as less reliable. The maturity of the technology plays a more important role than the interface.

    3. Re:Reliability by Ahtha · · Score: 2, Informative

      I agree there are reliability problems with ATA. We expect ATA disk failures within the first year for all of our ATA RAID systems and have yet to be disappointed. ATA drives just don't seem to be able to handle the pounding they get in a RAID configuration. We still use them, however, mirroring the ATA RAID with another server/disk installation as a backup. Of course, that doubles the cost of the ATA solution, but, it's still cheaper than a SCSI solution.

    4. Re:Reliability by Anonymous Coward · · Score: 0

      And what is the relative system reliability of $1000 worth of SCSI drives vs $1000 worth of ATA drives when connected into a redundant system? (If you point out that an individual failure is more likely with multiple parts, then you totally fail it, because the question regarded overall system reliability, not the irrelevant likelihood of a non-catastrophic subsystem failure)

    5. Re:Reliability by Slashcrap · · Score: 0, Troll

      People often forget there is a considerable difference in the reliability of ATA drives versus SCSI. If you are going to use some sort of ATA based SAN be prepared for disk failures much sooner than if they were SCSI.

      I would just like to say something to the people who modded this "Interesting". You are killing Slashdot with your stupidity.

      Now crawl back under your rocks, you fucking imbeciles. That is all.

      PS. To the original poster - if you don't understand something, don't comment on it. Is that really too much to fucking ask?

      PPS. You still don't fucking get it do you? Well, this will blow your mind - you can run ATAoE with SCSI discs. And vice versa.

    6. Re:Reliability by dfghjk · · Score: 1

      I think you mean availability. Redundancy doesn't improve reliability, in fact it lessens it. What redundancy does is offer availability, the ability for a system to remain available after a failure.

      The answer to your question is that, assuming there are more ATA drives of assumed lower reliability, the ATA system will be less reliable. You, sir, total fail it.

    7. Re:Reliability by Ryan+Amos · · Score: 1

      It has less to do with the interface and everything to do with the drive mechanisms. SCSI drives are more expensive not because they use SCSI, but because the customers who use SCSI would rather pay a little more and have a drive that is more reliable.

      Even the enterprise and datacenter are starting to use SATA for the vastly superior price per GB over high speed SCSI or FC drives in tiered storage systems. Store the bulk of your data on cheap SATA drives in a RAID5, then when you use it, move it to a 15k RPM SCSI drive.

      Drive failure is really not much of an issue; you'll likely be using RAID5 or 5/0 with a hot spare with any SATA configuration and the odds of 3 drives failing at once are astronomical. Not to mention that a 500 GB SATA drive costs less than an 80GB 15k RPM FC drive, so if it fails, just buy another.

    8. Re:Reliability by Anonymous Coward · · Score: 0

      No, you fail it. Embarassingly, because I specifically called out the error you made even before you made it.

      If a subsystem component fails in such a way that the overall system continues to function as designed, no system failure has occured.

      The expected number of annual system failure events will be lower with the redundant system. It is more reliable.

      The expected number of annual non-critical subsystem failures will be higher with the redundant system. It is also completely irrelevant, beyond its impact on calculating TCO, after the system has been designed.

    9. Re:Reliability by dfghjk · · Score: 1

      "If a subsystem component fails in such a way that the overall system continues to function as designed, no system failure has occured." Because you say so. If a system is "designed" to crash when it's hard drive fails then no system failure occurs then according to your definition. You asked for the "relative system reliability" but never defined what that was. You still haven't, yet you declare your correctness without ever demonstating that you even understand common terminology. From http://www.sun.com/products-n-solutions/hardware/d ocs/html/817-3881-11/ras.html: "Reliability, availability, and serviceability (RAS) are aspects of a system's design that affect its ability to operate continuously and to minimize the time necessary to service the system. Reliability refers to a system's ability to operate continuously without failures and to maintain data integrity. System availability refers to the ability of a system to recover to an operational state after a failure, with minimal impact. Serviceability relates to the time it takes to restore a system to service following a system failure. Together, reliability, availability, and serviceability features provide for near continuous system operation." Fact is that your original question cannot be answered because you never defined "system", never gave MTBF numbers for drives, never gave costs of SCSI or ATA drives, never offered configurations, and never provided MTBF numbers for common components. All you specified was $1000 in drives for either case. It appeared that you didn't know what you were talking about and it still does. Now, if your point was that a more useful system can be constructed with ATA drives than SCSI for the same price then I might agree with you. Reliability differences between SCSI and ATA are mainly artificial and imagined anyway. Drives should be classified as enterprise and non-enterprise, not ATA and SCSI. Protocol is meaningless. Once that is accepted, the original RAID paper makes your point well enough.

    10. Re:Reliability by shakah · · Score: 1
      If you are going to use some sort of ATA based SAN be prepared for disk failures much sooner than if they were SCSI.

      ftp://ftp.research.microsoft.com/pub/tr/TR-2004-10 7.pdf

      Section 3 ("Operations Experience") starting on p 16 is interesting, along with Section 4 ("Conclusion") starting on p 19:

      "We already knew that SATA disks and white-box PCs could meet the performance requirements because of testing done in October 2003 [Barclay03]. We were frightened into thinking the failure rate of the SATA disk drives would be 100%. The actual annual failure rate has been 6.4% which is reasonably close to the 5.5% SCSI disk failure rate. The SATA drives combined with the reliability and performance of the 3Ware RAID controllers are formidable competitors to SAN technology at a fraction of the cost."
    11. Re:Reliability by Anonymous Coward · · Score: 0

      "If a subsystem component fails in such a way that the overall system continues to function as designed, no system failure has occured." Because you say so.

      And I say so because the system is still working. It has not failed. The system continues to "operate continuously without failures and to maintain data integrity."

      If you have a server with redundant PSUs, and one of them goes out, but the other one takes over completely without interruption, then one of the PSUs has failed. The server has absolutely not failed. If you have to down the server to replace the bad PSU because you can't hot-swap it, then the system has lesser availability than one in which you can hot-swap. This is entirely orthogonal.

      Now you're retreating into pedantry, kicking up sand, pointing out irrelevancies, and finally grudingly admitting that I'm right without admitting that you're wrong.

      If my question cannot be answered because it's underspecified, then you can't turn around and say that the answer implied by the fact that I asked it is incorrect without contradicting yourself.

      Next time, either gracefully admit fault, or don't post in the first place.

    12. Re:Reliability by Anonymous Coward · · Score: 0

      SCSI drives are built and firmware'd for the sole purpose of running a server, and they consistently beat any ATA drive (be it IDE or Serial) when it comes to server performance and reliability.

      Performance and reliability don't always go together. SCSI is organized to improve performance when you have multiple simultaneous disk I/O requests. Multiple requests is typical in a server, but rare in a desktop, which is why ATA works so well for desktops, and the performance boost of scsi rarely justifies the cost in a desktop.

      ATA drives just aren't built to handle the sort of usage a server requires

      They could be, and some certainly are. I haven't had an ATA disk failure in the 50-odd desktops in my company in over 2 years. By comparison, I've had two scsi disk failures in raid arrays in that time, and these are 15k rpm enterprise drives. Of course, the servers are running 24x7.

      But a file server (which is the only thing the SAN would be used for)...

      SANs are routinely used for other things besides file serving. Large email servers, sql databases, really any application that you would use a raid in a regular server.

    13. Re:Reliability by dfghjk · · Score: 1

      Same could be said to you. Good to see you've finally used standardized terminology for the first time. Who said you couldn't learn anything?

      Since you didn't define system, you can't define, after the fact, what constitutes a "failure". It is commonly accepted that reliability refers to the unlikelihood of failure. When you buy a system or a component, that characteristic would be specified using MTBF and does not consider redundancy. In a redundant system, a different measure (MTDL) is used to indicate the likelihood of "failure" you refer to. Servicably is measured through a third term, MTTR.

      "If you have a server with redundant PSUs, and one of them goes out, but the other one takes over completely without interruption, then one of the PSUs has failed. The server has absolutely not failed."

      Depends on what you mean. The system remains available but there has been a failure and there is a degraded state. That's why additional language is valuable and exists. If I paid my money and the PSU died I'd be inclined to say the system failed even though that would be naiive.

      Furthermore, with your definition the backup component doesn't even have to take over without interruption since it would only be a requirement if the system design dictated that it was. A PSU is a bad example of this, but automatic rollover isn't always implemented when propagating a failure upstream can suffice. When that is considered there may, in fact, be an interuption in availability but the "system" (cluster) remains functional. An extreme example of this is Google. They let failed nodes die in place and never get serviced or removed from the rack.

      "If you have to down the server to replace the bad PSU because you can't hot-swap it, then the system has lesser availability than one in which you can hot-swap."

      It means that the system is not designed for a nonstop application. How MTTR is calculated for a hotplug device I don't know, but if it's 0 then you are right. Percentage-wise, not many applications require no scheduled downtime.

      "This is entirely orthogonal."

      What is?

      There is a common, decades-old language that describes these matters. If you were as knowledgable in these matters as you let on, one would think you would speak in those terms.

      Another reference to reliability vs. availability: http://www.barringer1.com/ar.htm

      This one tends to speak of reliability only in terms failure rates of components.

      "Next time, either gracefully admit fault, or don't post in the first place."

      Thanks for the advice and same to you, AC.

    14. Re:Reliability by _damnit_ · · Score: 1
      reliability of SCSI versus ATA is largely imagined and the rest is intentional. drive manufacturers want you to believe their enterprise drives are more reliable and right now those drives are largely SCSI.

      I disagree. There is a difference in product quality.

      Read this: http://www.usenix.org/publications/login/2006-06/o penpdfs/chan.pdf

      There are real differences in performance and reliability on hard drives.
      --


      _damnit_

      It's my job to freeze you. -- Logan's Run
    15. Re:Reliability by dfghjk · · Score: 1

      take the word of someone with a vested interest in selling you enterprise drives, but i stopped reading when he claimed a 20% likelihood of an unrecoverable read error on a single sweep. what bullshit!

    16. Re:Reliability by dfghjk · · Score: 1

      incidently, his calculation of 20% was off by a factor of 5x (should have been 4%). Sounds bad, but the server drive rating was lower not only because of the improved rating but because the drive was less than 40% the size! Lesson is only use small drives if you want reliability. Right ;)

      The guy has a vesting interest in producing FUD and has done so. Anyone believe that their drive is going to fail after 5 surface scans?

    17. Re:Reliability by Anonymous Coward · · Score: 0

      I hate bad losers.

      GET A JOB!

    18. Re:Reliability by afidel · · Score: 2, Informative

      the odds of 3 drives failing at once are astronomical.

      No, they aren't. Just have an array running for a year or two and bring it down for maintenance, your chances of multiple drive failures are VERY good. Of course that happens even with SCSI drives, but it even more underscores the need for a premium part. Btw I just live through a scare this weekend. We lost one drive after powering up one of our main DB servers, then lost a second about 10 minutes later, luckily the 16 drive array was setup as RAID6 instead of RAID5, the first good decision we have found from the previous staff =)

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    19. Re:Reliability by Kent+Recal · · Score: 1
      Anyone believe that their drive is going to fail after 5 surface scans?

      I don't think that would ever happen. I just bought this fresh new... hrmmm, wait.. what's this clicking noise..
    20. Re:Reliability by dfghjk · · Score: 1

      Haha yeah. Never buy Iomega.

      BTW, when a nonrecoverable read error occurs the controller will simply retry it. Another is unlikely to occur for another terabyte or so. That guy is shameless liar. These rare failures are a nonissue.

  7. PoE, AoE, ... , EoE! by adavies42 · · Score: 1, Funny

    Everything over Ethernet!

    --
    Media that can be recorded and distributed can be recorded and distributed.
    -kfg
    1. Re:PoE, AoE, ... , EoE! by Volante3192 · · Score: 0

      I was thinking Ethernet over Ethernet. TCP/IP packets encapsulated within themselves...

    2. Re:PoE, AoE, ... , EoE! by Anonymous Coward · · Score: 0

      so will it be more like virtual ethernet or rather ethernet virtualization?

    3. Re:PoE, AoE, ... , EoE! by pyite · · Score: 1

      I was thinking Ethernet over Ethernet. TCP/IP packets encapsulated within themselves...

      Pretty impressive... considering Ethernet has no knowledge nor concept of TCP/IP.

      --

      "Nature doesn't care how smart you are. You can still be wrong." - Richard Feynman

    4. Re:PoE, AoE, ... , EoE! by Anonymous Coward · · Score: 0

      There's always PPPoEoE!

    5. Re:PoE, AoE, ... , EoE! by Anonymous Coward · · Score: 0

      Ethernet over Ethernet? You're thinking of VLANs.. been there, done that.

    6. Re:PoE, AoE, ... , EoE! by tduff · · Score: 1

      Sounds like Plan 9.

    7. Re:PoE, AoE, ... , EoE! by Anonymous Coward · · Score: 0

      Just..don't bother. Trying to get the vast majority of Slashdot readers to understand basic concepts such as the ISO 7 layer model, or the difference between an Ethernet frame and an IP packet, or what that little slash character in the middle of TCP/IP actually means, is a pointless excercise. You'd be better off trying to teach your dog to tango.

    8. Re:PoE, AoE, ... , EoE! by Duhavid · · Score: 1

      PoE ? Purity of Ethernet?

      --
      emt 377 emt 4
    9. Re:PoE, AoE, ... , EoE! by skids · · Score: 1


      Especially STDBToE: the stuff that doesn't belong there over ethernet!

    10. Re:PoE, AoE, ... , EoE! by imemyself · · Score: 1

      Power over Ethernet. Its used to provide power to devices over the network cable. So, for example, some Cisco access points can pull power directly from its network connection, so you don't have to worry about power outlets in the ceiling. And you can also reset the AP's easily (unlplug them from the switch).

      --
      Every time you post an article on Slashdot, I kill a server. Think of the servers!
    11. Re:PoE, AoE, ... , EoE! by Duhavid · · Score: 1

      I was playing off the PoE in Dr Strangelove.

      General Ripper wrote PoE all over everything
      and used it as the encoding for the CRM
      discriminator. Stood for Purity of Essence.
      And some other things also, I think.

      --
      emt 377 emt 4
    12. Re:PoE, AoE, ... , EoE! by keithmo · · Score: 1

      You joke, but that was one of the (many, excellent) points of Van Jacobson's recent net channels presentation. From his slides:

      Networking gear has gotten fast enough (10Gb/s) and cheap enough ($10 for an 8port Gb switch) that it's changing from a communications technology to a backplane technology.
  8. How does it lower costs? by Unknown+Relic · · Score: 1

    TFA isn't responding, so maybe I'm missing something but how does this new protocol actually result in cheaper costs per GB? It's already possible to get an iSCSI SAN which uses SATA drives, and one of the major cost differences is the type of drive. What else is new here?

    1. Re:How does it lower costs? by Unknown+Relic · · Score: 2, Informative

      Oops, only the linux journal article is down, the cnet article has answered my question: it isn't any cheaper than iSCSI + SATA solutions. $4,000 without any drives, compared to a starting price of $5,000 for a StoreVault (new from NetApp) with 1TB of storage. Other options such as Adaptec's Snap Server start just as cheap.

    2. Re:How does it lower costs? by wasabii · · Score: 1

      Just slightly less overhead than iSCSI. It's the same shit though.

    3. Re:How does it lower costs? by Anonymous Coward · · Score: 0

      You can buy a Norco 1220 storage chassis for $800, and build/buy a cheap server for $500. That is $1300 for your enclosure in a total of 4U, supporting 12 disks. If you build a half-depth server, you might be able to squeeze them into a combined 3U. Install Linux on the chassis and run "vblade" from the AoE tools package, alternatively, run NDBD instead.

      Will it be the most "enterprise" system? No, but it *will* be relatively cheap. I just built mine.. $500 for disks, $800 for the chassis, and used an existing server. I now have 1.28 tb of usable storage and 7 free slots for additional disks for $1300 out of pocket -- although it would've been $1800 if I had needed to buy a new server.

    4. Re:How does it lower costs? by swillden · · Score: 1

      TFA isn't responding, so maybe I'm missing something but how does this new protocol actually result in cheaper costs per GB?

      The idea is that iSCSI uses TCP, which requires a lot of additional processing, which bogs down both the machine using the storage and the machine that contains the storage. The solution usually recommended is to buy expensive network cards that offload the TCP overhead from the main CPU. With AoE, you don't have the TCP overhead and therefore don't need the more expensive TCP-offloading network cards, resulting in a lower overall cost.

      Given the cost of main CPU cycles, though, it seems to me that most systems will have the cycles to spare on TCP overhead. On the other hand, unless you really need your remote storage protocol to be routable, it's not clear that iSCSI has _any_ advantages over AoE, at least from a purely technical perspective.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    5. Re:How does it lower costs? by dfghjk · · Score: 1

      "Given the cost of main CPU cycles, though, it seems to me that most systems will have the cycles to spare on TCP overhead."

      not at 10G they won't.

      the question isn't whether iSCSI or AoE is better but rather why you would use either of them.

      Will there be any 10G NIC's that don't offer offload engines? If not, what is the advantage architecturally of AoE?

      What about direct DMA and zero-buffer?

    6. Re:How does it lower costs? by swillden · · Score: 1

      the question isn't whether iSCSI or AoE is better but rather why you would use either of them.

      I think the costs and benefits are pretty clear. I'd actually love to see some drives with AoE/iSCSI built into them for home use. Need more storage for your video collection? Just buy an AoE/iSCSI drive and plug it into your switch. Although it would be done differently, unlimited expandability is the main advantage for enterprise environments as well. I don't know how this notion compares with SAN solutions, really, except that I know people complain SANs are very expensive and hard to manage.

      Will there be any 10G NIC's that don't offer offload engines?

      Yes. As prices on the 10G NICs come down, the norm will be to do TCP header parsing and checksumming on the main CPU -- since even desktop systems are all going to have at least two cores in the near future, there will be plenty of cycles. Some of the first 100BaseT NICs had offload engines, and lots of the first Gig-E NICs did, too, but it always works out that offloading only makes sense for specialized applications.

      What about direct DMA and zero-buffer?

      What about it? Most (all?) current NICs support DMA, and there's no reason you can't implement zero-copy from the network card just as easily as from a drive controller. Perhaps I'm missing your point.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    7. Re:How does it lower costs? by dfghjk · · Score: 1

      Direct DMA (zero buffer) is hard to do, not easy. Yes, NIC's have DMA capability but that's not what I'm referring to. Ideally you would like a data request to be satisfied between the storage device and the data buffer itself, even if it's a buffer in the app, without any intervening copies. Currently data is copied many times. IB offers this. Current filesystems don't.

      None of this is being done for the home user, so if you see this from that perspective you aren't really understanding it.

      iSCSI, and now AoE, were done as competitors to FC and InfiniBand. The argument for ethernet there is obviously cost and ubiquity. Problem was that 10GigE would REQUIRE TOE's in order to get the throughput so the assumption that TOE's will be optional is just that. AoE is obviously intended to eliminate the requirement of TOE's. Supporters of IB, me for one, aren't terribly excited about using ethernet for the purpose. Lots of things will need reinventing and it sets back the industry years.

    8. Re:How does it lower costs? by swillden · · Score: 1

      iSCSI, and now AoE, were done as competitors to FC and InfiniBand.

      Ah, I see where you're coming from now. I agree that they aren't going to compete with FC or IB in terms of performance. I see them as being useful in environments where performance is less important than low cost and easy expansion.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    9. Re:How does it lower costs? by Tracy+Reed · · Score: 3, Informative

      I think you are probably looking at the cost to buy Coraid's gear. You do not have to buy their stuff, although I am sure that they prefer that you do. I built my own AoE SAN using regular PC's. Way cheaper. I take the google approach: Use a larger amount of commodity hardware and design the system in an intelligent way to achieve the same performance and reliability at a better price/performance. Coraid hardware is basically just a Linux box with disks exporting AoE volumes. The nice thing about it is that you get their support. But AoE is so simple that you generally don't need support beyond perhaps the mailing list.

    10. Re:How does it lower costs? by dfghjk · · Score: 1

      I agree there. Unfortunately, iSCSI fans believes it will. FC needs replacement and IB has had trouble getting traction since the market crash.

      I would like to see a cheap, high performance NAS solution. TCP and SMB/NFS isn't it.

  9. Yes! by mihalis · · Score: 3, Interesting

    I like the look of this technology. The great thing it has going for it is that most of the non-hard-disk infrastructure (switches and cabling) leverages the tremendous investment in ethernet. That is great.

    The thing that needs work, in my view, is that the bit that links the disks and the rest isn't cheap enough. In fact what would be awesome here is if, say, Seagate provided disks with native ATAoE connectors built-in. They might have to buy Coraid for that to happen.

    In case anyone thinks I'm out of my mind here, don't forget that disks can already be had with ATA interface, SCSI interface, FCAL interface, SATA, SAS - that's five and there are probably more. Yes they might be a bit more expensive, but if they come in under the combined price of "regular ATA disk" + Coraid ATAoE disk adapter then you'd come out ahead. Someone like Seagate would, I think, have the industry-wide clout and respect to succeed in making this an open standard. Something that will be a challenge for Coraid for a long time (I have nothing against them, btw, they are friendly and their mailing list didn't spam me when I signed up).

    When I was on the OpenSolaris pilot project I tried to get people interested in using this with Solaris. I think it might be great for ZFS, for example. At that point the real storage wizards were more interested in iSCSI, but I respectfully disagree, OpenSolaris + ZFS + cheap storage = awesome file server. Emphasis on the cheap. As Sun people will admit, their previous attempts at RAID were more like RAVED (Redundant Array of Very Expensive Disk). Coraid does have a Solaris driver, so this is definitely feasible.

    1. Re:Yes! by MoxFulder · · Score: 1

      How much actual logic is needed to allow a hard drive to communicate in ATAoE? I haven't read the spec, but from the article it seems like not very much... basically the normal ATA packet needs some kind of ATAoE header prepended, and then it gets pumped directly into an Ethernet MAC.

      These days, an embedded Ethernet controller adds, say, $10 to the total cost of a device. And hard disks already have onboard intelligent controllers, so getting them to speak the ATAoE protocol shouldn't be much more than a firmware update.

      So, I agree with you. It seems totally feasible to manufacture drives which speak ATAoE natively, with a little RJ-45 jack in back. Stack 'em up, patch them into a switch, and you'd be good to go...

    2. Re:Yes! by magetoo · · Score: 1
      Hmm. I don't know. Plugging one drive directly into the network switch is going to be simple and neat, but when you're plugging in several, you might start to wonder if every one of them really needs to have a separate cable to a switch that is essentially just a "disk multiplexer". Let the switch speak SATA instead, and the drives be cheap.

      And you need power to those drives too. So even with only one or two drives, you still need additional hardware. It seems to me like it's better to just have a specialized disk switch, even before going into wanting to have the disks on their own separate network.

    3. Re:Yes! by matthew.coulson · · Score: 1

      Couldn't PoE be used?

      Bunch of cheap disks, cheap PoE switch, a little Mini-ITX machine. As far as I'm concerned, that's elegant hackery.

    4. Re:Yes! by Electrum · · Score: 1
      OpenSolaris + ZFS + cheap storage = awesome file server ... Coraid does have a Solaris driver, so this is definitely feasible.
      Your post is misleading. ZFS is only available on Solaris 10. The only driver available from Coraid for Solaris 10 is in beta and it does not support x86.
    5. Re:Yes! by drinkypoo · · Score: 1
      Hmm. I don't know. Plugging one drive directly into the network switch is going to be simple and neat, but when you're plugging in several, you might start to wonder if every one of them really needs to have a separate cable to a switch that is essentially just a "disk multiplexer". Let the switch speak SATA instead, and the drives be cheap.

      I don't think that this is going to save any money. You can purchase devices from several people that get loaded up with ATA or SATA disks, and which present a SCSI interface (usually only UW-scsi, not LVD or U160+) to a host machine, appearing as a single hard drive. They're a lot cheaper than building (for example) a whole FC array but that's about as far as it gets.

      Arguably, you could have some $100 dongles that consist of an embedded system with a single ATA interface, and a GigE interface, that would boot up a kernel and maybe a single process, and connect to the drive and offer it to the network via AoE. coraid wants $4000 for a device that will manage fifteen drives; you could spend $266 per drive without costing more. If they were $200 per drive, it would still be cheaper, and more flexible to boot.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    6. Re:Yes! by Lisandro · · Score: 2, Funny

      I like the look of this technology.

          It's the eyeliner. It doesn't look half as good in the morning.

    7. Re:Yes! by magetoo · · Score: 1
      Yes, I suppose so. But then you're using "special" (more expensive) drives and switches, and it might be better value for money for home users just adding a couple of plain SATA drives to the box you already have.

      Or if you want to have lots of storage, and RAID, adding more than a couple of plain SATA drives to the mini-ITX box you mentioned. And no need for a switch there.

      I don't know. There might be a perfect niche for it, but I don't see it.

    8. Re:Yes! by mihalis · · Score: 1

      Your post is misleading. ZFS is only available on Solaris 10. The only driver available from Coraid for Solaris 10 is in beta and it does not support x86.

      Sorry if you found it misleading, but I don't agree. I was talking to Solaris -developers- about this protocol. It was a forward-looking prospect. At the time ZFS was not even released, but I liked the sound of it for some future time, and I also like the sound of AoE so I figured the two might combine nicely. If I had the time I'd get the dev hardware, the beta driver and have a go myself (which is of course possible now that Solaris is open source). Sadly I don't, but I still think it's an intriguing project (not product, not solution, development project - work to be done).

    9. Re:Yes! by Wesley+Felter · · Score: 1

      For ZFS I think SAS JBODs are a better solution that AoE. And AoE will get squeezed even more when SAS SANs arrive.

    10. Re:Yes! by labratuk · · Score: 1
      Yes they might be a bit more expensive, but if they come in under the combined price of "regular ATA disk" + Coraid ATAoE disk adapter then you'd come out ahead.

      Ah, but then when a disk fails you have to throw away the expensive integrated controller. With the current Coraid systems, when a drive fails, you just replace the drive with another cheap drive ad infinitum.
      --
      Malike Bamiyi wanted my assistance.
  10. iSCSI killer? by apharov · · Score: 4, Interesting

    In the context of using this in low-cost environments with Linux I can hardly see how this could kill iSCSI. Last week I implemented an iSCSI setup for about 500 euros (target serves out 500GB disk space for non-critical backup) using standard components, FC5, iSCSI Enterprise Target and Microsoft iSCSI Initiator.

    Works great and is a lot (>10x) faster than the about similarly priced NAS device that was used for the same task before.

    1. Re:iSCSI killer? by sloth+jr · · Score: 1

      I agree. We're really just talking about the transport layer, since the targets can be whatever kind of device the host supports and that the target unit makes available. So, AoE seems a little - redundant, I'd guess. The SCSI standard is well-defined, been around forever, so I'm not sure why a re-implementation using an ATA command set would make much sense.

      sloth jr

    2. Re:iSCSI killer? by Kenshin · · Score: 1

      I've got an iSCSI killer.

      It's called soap.

      Jeez... didn't your parents teach you proper hygiene?

      --

      Does it make you happy you're so strange?

    3. Re:iSCSI killer? by Anonymous Coward · · Score: 0

      10 times faster! What makes that kind of difference? Was it the crappy CPU in the NAS, did you switch to gigabit, move from laptop drives to a SCSI RAID, put 4 gig of RAM in the server and test with a 1 gig file or a combination of all of the above?
      Seriously, if you got 10 times the performance out of similar hard drives this is a much bigger deal than I thought, and something we should all know about.

    4. Re:iSCSI killer? by apharov · · Score: 1

      Replying to AC, but here it goes:

      I would guess it is a bit of most of those. CPU is AMD64 (vs. some embedded level CPU), I did switch to gigabit (although testing with 100Mbit also produced good results). The hard drives were however about the same (3,5" 7200RPM same generation) and memory was "only" 1GB.

      I measured the performance with IOzone. I would guess the difference in performance is mainly caused by processor speed and larger memory.

    5. Re:iSCSI killer? by cerberusss · · Score: 1

      The iSCSI protocol uses TCP/IP for its data transfer. AoE only uses Ethernet and so supposedly has a lower overhead.

      --
      8 of 13 people found this answer helpful. Did you?
    6. Re:iSCSI killer? by dfsmith · · Score: 0

      Unless you use two AoE drives.... (Last year I read a performance review of AoE vs. iSCSI: TCP scales pretty well with multiple connections, AoE didn't. Maybe they've corrected it now.)

    7. Re:iSCSI killer? by Anonymous Coward · · Score: 0

      Cheers for the reply. Shame there's no magic involved. I guess the NAS was quite a bit cheaper - you get what you pay for...

  11. iSCSI can talk to ATA drives by Anonymous Coward · · Score: 2, Insightful

    iSCSI is a protocol. ATA disks are a physical medium. They work together, and you get the benefits of SCSI commands with the price of ATA disks. Just because iSCSI is the protocol does NOT mean that you need to use SCSI disks. You might even be talking to a RAID of ATA disks and not know it.

    So, why would you need AoE? It's already cheap, and been for sale for some time.

    1. Re:iSCSI can talk to ATA drives by dfghjk · · Score: 1

      to go fast?

      what are the benefits of SCSI commands for storage? Oh yeah, command queuing. ATA has that.

    2. Re:iSCSI can talk to ATA drives by g33uu · · Score: 1

      You might even be talking to a RAID of ATA disks and not know it.

      Sincerely,
      The Department of Redundancy Department (pardon the pun)

    3. Re:iSCSI can talk to ATA drives by Anonymous Coward · · Score: 0

      You seem to have a reading comprehension problem. The question asked was why you need AoE when iSCSI can already be used with ATA drives? According to TFA, the one supposed advantage of AoE is that it uses cheaper ATA drives. But if iSCSI can use the same drives then it is still the better solution since it is otherwise more robust than AoE.

      So the question remains, why use AoE?

    4. Re:iSCSI can talk to ATA drives by labratuk · · Score: 1
      So, why would you need AoE?

      Because it's simpler (== cheaper disk 'dongles') and slightly faster.
      --
      Malike Bamiyi wanted my assistance.
  12. Bootable? by Anonymous Coward · · Score: 2, Interesting

    Is it possible to boot WindowsXP via AoE or iSCSI? I want a diskless WindowsXP box.

    1. Re:Bootable? by EndlessNameless · · Score: 1

      The BIOS would have to support booting from AoE. OS support from the vendor is irrelevant, as the AoE driver makes the disk accessible in the same manner as an internal ATA disk.

      Since most x86 BIOSes only support PXE as their network boot protocol, I doubt it will work out of the box. Something would have to provide block-level access to the HD in order for the OS to bootstrap, and PXE doesn't do that.

      Coraid (or someone else) would have to make a bootable floppy, CD, or flash drive image that could add this functionality.

      Alternatively, a CF card with an IDE adapter could work as an internal solution. With a sufficiently large CF card, you could even install the OS onto the card and use the AoE drive for user profiles, applications, and storage (don't know about performance when swapping though... even with GigE, you might just want to do this on a system that has 2+ GB RAM). This is still technically diskless, and it is feasible with existing hardware and software. If you really want a diskless system now, this is my recommendation.

      --

      ---
      According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
    2. Re:Bootable? by Petersson · · Score: 1

      Well, boot linux from flashdisc and start vmware.

      --
      I'm not insane. My mother had me tested.
    3. Re:Bootable? by Anonymous Coward · · Score: 0

      Yep, you'd buy an iSCSI HBA which has the capability of hooking int 13. The BIOS of the actual pc/server is then irrelevant.

      keep in mind that the iSCSI target should also support boot (i think).

    4. Re:Bootable? by KingMotley · · Score: 2, Informative

      Yes, you can. Just look for an iSCSI PCIe card. It's basically an ethernet card that looks like a standard ethernet card and disk controller (Most are SCSI controllers, although there is no reason they couldn't make it look like an ATA controller, but you'd lose a lot of features).

    5. Re:Bootable? by wild_berry · · Score: 2, Insightful

      My inexpert guess would involve getting a Tyan Thunder/Tiger motherboard with LinuxBIOS and compiling and configuring your own ATAoE support. Windows would need to think it's a local disk; LinuxBIOS could pretend that it was.

    6. Re:Bootable? by eno2001 · · Score: 1

      This is a point that a lot of people will miss. Most of us interested in this sort of set up will likely have one server that serves the storage out using a combination of LVM and RAID. This brings all the storage adiministration to one local machine instead of leaving it up to the systems that are attaching. The second point that is brought up in the post I'm responding to has to do with virtual machines. I'm using Xen (as it outperforms everything else) and it would certainly be able to handle the volumes handed out to Domain0 for support within Domain1, Domain2, etc... This means that you don't need any extra hardware to pull off booting from an AoE box. Just virtualize everything. It's a beautiful idea. I've been exploring GNBD (Global Network Block Devices) myself for this but AoE seems to be a bit more interesting.

      --
      -"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
  13. Not an iSCSI killer, here are the reasons why not by cblack · · Score: 4, Insightful

    1) Complexity for RAID and volume management is not centralized and is pushed to individual hosts. One of the main benefits of SAN technology is that you can just carve out storage from a single interface and assign it to a server and the server simply sees it as a block device. With AoE each drive is addressed separately by the server, which means it is up to the server (and server admin) to figure out how to handle distributing over multiple drives, handle drive failures, and expanding volumes. This is huge.
    2) It is not a standard and is only really supported by one vendor. This may change in the future but it is significant right now. It is registered with the IEEE but that hardly makes it a peer-reviewed standard with input/improvements from many experts.
    3) No boot from SAN. Until someone makes some sort of mini bootstrap system on a CD or a hardware card implementation of AoE that can be addressed as a block device admins will be unable to host the root filesystem and/or C: drive on an AoE SAN
    4) No multipath (that I can see). Perhaps I misunderstand this, but it seems like there is no way to do multipath IO with this system. That is, all the drives are single-connected to a network. If that network switch goes down, all drives on that network are inaccessible.
    So AoE looks like a neat technology for pushing drives out of the box and potentially sharing them among hosts, but there is no intelligence there. It is just dumb block addressable storage with no added availability or management, and therefore is far from being an iSCSI or FC killer.

  14. Not so much cheaper by err666 · · Score: 2, Insightful

    Ok, so the Coraid people are selling their ATA over Ethernet 15 slot version for $3,995.00. That's apparently around EUR 3133. I can get something proven iSCSI based from Promise here in Germany for 4.499,- (a Promise M500i). Ok, that is almost 50 percent more expensive, but the iSCSI solution is supposed to work under all operating systems (Linux, *BSD, Windows, etc.) more or less out of the box, while for AoE you will have to buy drivers for Windows, and has generally worse support for other operating systems.

    Now, suppose you will really use this baby and you want to have *lots* of storage.

    So you buy 15 SATA drives, like say Seagate ST3750640NS for EUR 444 each. Now the difference between AoE and iSCSI becomes less:

    AoE solution: EUR 9793
    iSCSI solution: EUR 11159

    Now the iSCSI solution is only 14 % more expensive.

    Now it would be clear for me to go for the "safe" path of something proven and widely supported like iSCSI instead of AoE. The infrastructe you need will be the same anyway (Gigabit Ethernet, Gigabit ethernet switch).

    --
    reduce(lambda x,y:x+y,map(lambda x:chr(ord(x)^42),tuple('zS^BED\nX_FOY\x0b')))
  15. Maybe I dont get it... by segfaultcoredump · · Score: 1

    From reading the news article, it seems that they are selling $3,995 ATA -> ethernet converters (disk sold seperately). Each box will hold 15 drives and offer a simple raid controller inside. It still has the same performance issues of iSCSI (a bit lower overhead, but not by much).

    I dont see what the point is other than the fact that they are offering yet another transport protocol. Given that one can install iSCSI target software on linux/solaris/windows... whats the point? Anybody who read the article on Sun's 4500 (48 500G drives w/ a dual proc opteron) know that you can cheaply assemble a box with a ton of drives, slap the iSCSI target software on it and call it networked storage. Redundancy sold seperately.

    I've seen FC -> SATA arrays that run around $10K for 6TB. And thats for a system with active/active controllers, mirrored cache and 4Gb FC interfaces. And these systems had the ability to expand to 120 drives on the same controllers (final price: around $1 per GB). I think that FC has a bad rep for being expensive due to companies like EMC and HP. If you know what to look for, you can actually get the stuff for a relatively low cost. Given the performance boost compared to iSCSI, I'm going to stick with FC for the time being (I will still pay for the EMC kit when it makes sense from a support/reliability standpoint, but I also mix in things from companies like NexSAN when cost is more important)

    1. Re:Maybe I dont get it... by Skreems · · Score: 1

      Adding to that... I just don't see the point at all. I priced out a home-level file server and came out to $0.53 per gig, and that's including a backup drive to swap in should one of the raid5 array fail. The rest of the hardware was SATA2, hypertransport system bus, dual core machine... I wouldn't expect it to have any problems at all maxing out 3 or 4 gigabit nics. So how is $1/G all that great?

      --
      Slashdot needs a "-1, Wrong" moderation option.
      The Urban Hippie
    2. Re:Maybe I dont get it... by labratuk · · Score: 1
      From reading the news article, it seems that they are selling $3,995 ATA -> ethernet converters (disk sold seperately). Each box will hold 15 drives and offer a simple raid controller inside.

      If you look a bit closer you'll see they also sell individual disk ATA-AoE adaptors, which are considerably cheaper.
      --
      Malike Bamiyi wanted my assistance.
  16. Re:Not an iSCSI killer, here are the reasons why n by Cyberax · · Score: 3, Interesting

    You can use Ethernet-based multipath IO, a lot of switches can be stacked to provide redundancy (and load-ballancing).

    AoE is a COOL thing exactly because it's a 'dumb' technology. You can buy a switch, a bunch of disk drives and AoE adapters, a small Linux PC - and your storage system is ready. There is a lot of existing RAID manipulation and monitoring tools for Linux, so RAID configuration is not a problem.

    You also can boot from SAN, it's not a problem. Just add required modules and configs to initrd and place it on a USB drive.

  17. ATAoE is a crock, it's no better than iSCSI by NekoXP · · Score: 3, Informative

    So. Coraid has not, in a whole year, explained why iSCSI is somehow more expensive (disks + Linux kernel + network.. all the same) than their ATAoE implementation.

    They'll give excuses about the cost of iSCSI hardware offload.. but you don't need that. ATAoE is all software anyway it's just a protocol over ethernet, rather than layered on top of TCP/IP.

    What is wrong with using TCP/IP - which is already standard and reliable? Nothing. We know TCP/IP provides certain things for us.. resilience (through retransmits), and routing, are a good couple, and what about QoS?

    ATAoE needs to be all the same network, close together, they're reimplemented the resilience, you can't use inbuilt common TCP checksum, segmentation and other offloads in major ethernet chipsets because they're a layer too low for it.

    No point in it. Just trying to gain a niche. They could have implemented products around iSCSI, gotten the same performance with the same features, for the same price. Bunkum!

    1. Re:ATAoE is a crock, it's no better than iSCSI by dfghjk · · Score: 1

      One of the problems of TCP is it's very hard to make go fast over 10G. All those issues become moot for AoE since it doesn't use that. GigE ethernet isn't really interesting for attaching large numbers of disks.

      Trouble is that I'd assume all 10GigE NIC's will come with offload engines anyway so there's no savings.

      There is no functional problem with making the product non-routable. Servers need physical security and physical proximity. What you seem to think is a liability is not one.

    2. Re:ATAoE is a crock, it's no better than iSCSI by NekoXP · · Score: 1


      Do you actually have an ATA RAID array that can perform 10 Gigabits/s full-duplex? I would love to see that, I really don't think those disks really exist though (maybe a couple or 10 10Krpm WD ones.. :)

      Right, so in the article this one guy says that "using the second network port and a dedicated switch adds more security". So despite being non-routable he gave it a dedicated network anyway. There's also a guy in the article talking about that he "believes" that iSCSI would have been harder to configure. I seriously doubt this, having set up a number of iSCSI networks. I don't think it's at all because he wants more security, or because he knows what he is talking about, but because he got told to configure it that way in the Coraid blade manual.

      The reason you'd dedicate a switch to ATAoE is probably purely because you would get some serious bandwidth conflicts with other TCP/IP applications.

      Even if you got an iSCSI network there you'd probably want to dedicate a switch to it too, but if you couldn't, or had to share the network with something else for some other reason, this is what QoS and traffic shaping is for. You can easily prioritise your disks over the other stuff. ATAoE.. I think you are stuck with buying another switch and buying client machines with two ethernet ports.

      You can easily stop TCP/IP from routing by using non-routable addresses or implementing a firewall between segments. You could even have this firewall on your server to restrict access to the disks from machines on the same network. This kind of security is ALSO offloadable (see latest Intel and nVidia chipsets).

      ATAoE reimplements it with "config strings"... buhhh...

      The problem with saturating a 10GE network is not down to TCP but ethernet frame size, too. If you have the network cards to handle a 10GE network they pretty much reduce the building of large TCP frames to zero like you said. Everything's offloaded already for iSCSI, or you can buy a card that offloads it.

      I suppose this is the expensive part! iSCSI initiators are costly, but really only because they are a rare form of ethernet card. If everyone used iSCSI they probably wouldn't be (you could bet that iSCSI initiator support would be in every nForce chipset..)

      So basically what they have is a requirement to use ATA disks only (as opposed to iSCSI where it can be any damned disk, even and ESPECIALLY relaying other iSCSI networks), bundled with an unoffloadable ethernet protocol, which they reimplemented all the best features of TCP/IP into, for the reason of.. .. what?

      I think I know! It's so they can sell "disk blades" and not have to "compete". Snake oil..

    3. Re:ATAoE is a crock, it's no better than iSCSI by imroy · · Score: 1

      There's nothing wrong with TCP/IP and iSCSI, that is until you try implementing it cheaply in hardware so that you can stick a little controller onto each of several dozen disks. That to me seems to be the point behind ATAoE - make it cheap and simple. And the reason to use a separate ethernet network just for ATAoE is because it's basically replacing the IDE/SATA/SCSI/FC connection. Don't think of it as a dedicated network, more of simply the cables that connect the disks to the host(s). They just happen to be ethernet cabling and switches.

    4. Re:ATAoE is a crock, it's no better than iSCSI by dfghjk · · Score: 1

      "Do you actually have an ATA RAID array that can perform 10 Gigabits/s full-duplex? I would love to see that, I really don't think those disks really exist though (maybe a couple or 10 10Krpm WD ones.. :)"

      I meant that it's hard to do 10GigE without a TOE. In rough terms 1GigE is 100MB/s and it's easy to swamp that with a modest number of disks. For servers you want 10GigE. Sorry for the confusion.

      Regarding a dedicated port and switch, I agree that it's what you want to do in any case.

      AoE forces nonroutability because they want the efficiency of of avoiding TCP, not for security reasons ;) I would assume that the ethernet protocol would be efficient enough to not require an offload engine.

      I agree though, not very interesting.

    5. Re:ATAoE is a crock, it's no better than iSCSI by slashjunkie · · Score: 1

      Running something like SCSI over TCP/IP does seem like quite a lot of overhead, but when you look closer, TCP/IP is handling a lot of things that AoE will have to implement at the application layer - things like reliable delivery, and ensuring correct sequencing of packets.

      Some people will wonder why we need the ability to route such a protocol (like yeah, as if we're going to run iSCSI over a WAN link). How about inter-VLAN routing though? It's probably in the same building, and on a gigabit LAN, but it's a different IP subnet, so it needs to be routed.... ok, you're gonna need a kickass L3 switch to avoid being a bottleneck, but...

      Of course, implementing iSCSI in software and using a standard NIC & driver will clearly be a bit sluggish. Use a NIC with a TCP offload engine and things get a bit faster. Use an actual iSCSI NIC and you're then doing about as much in hardware as you can.

      Then there's iSCSI over IPv6, which is supposedly faster to process the IP header of, than IPv4.

      So yes, AoE certainly would be a leaner protocol than iSCSI, but by the time you add checksums, reliable delivery, sequencing, and routing (with only a MAC address??), you've probably reinvented TCP/IP.

      So who's going to be the first to come up with AoI (ATA over IPX), AoD (ATA over DECnet), and AoA (ATA over Appletalk)?

    6. Re:ATAoE is a crock, it's no better than iSCSI by labratuk · · Score: 1

      I think you're really missing the point of AoE. It's not meant to compete with NFS, SMB etc. for serving files. It's meant to be an alternative to the server -> disk interface, like SATA. This is why they produce 'blade' interfaces for one drive each.

      Why would you want an alternative to SATA(/IDE/SCSI)? Because you don't (necessarily) get hot swapping with SATA. SATA isn't as expandable - for each ~4 new drives you need a new PCI card. Limited to the number of PCI slots in your machine. If you have to expand the system and break out of the server case with the number of disks you need, SATA isn't very cooperative (although there is such thing as external SATA I hear).

      It's a cheaper alternative to Fiber Channel.

      It's using the fact that people have already solved the problems of hot swapping, scalability and low(ish) latency data transfer with this thing called ethernet. Need more disks? Use a bigger ethernet switch and spill over into the next server closet.

      From what I can see, it's not really meant to be a system where a host is exporting volumes to another host, although a daemon for that is available for testing etc. After all, if you really wanted to do that you could use nbd.

      --
      Malike Bamiyi wanted my assistance.
    7. Re:ATAoE is a crock, it's no better than iSCSI by NekoXP · · Score: 1

      It exports ATA over Ethernet.

      Which forces you to use ATA disks..

      And Ethernet.

      iSCSI exports... disks.... over... a TCP/IP network. It's not more expensive UNLESS you are figuring fiber channel and special initiator cards, in fact it is more flexible, you can pick up any hardware, any disk type (ATA, SATA, SCSI, ...), network it how you want, any topology or connection and all the things you want are there to get what you need.

      I don't see the point in it, since iSCSI is not bound to fiber channel nor does TCP/IP overhead really matter (I think you'd lose a lot more to reimplementing TCP/IP features in software, at the end of the day)

    8. Re:ATAoE is a crock, it's no better than iSCSI by labratuk · · Score: 1

      IP stacks can be really significant when you're dealing with gigabit ethernet.

      AoE is simple enough to make relatively inexpensive single drive interfaces possible.

      --
      Malike Bamiyi wanted my assistance.
  18. EoE! by Anonymous Coward · · Score: 0

    I prefer the hardwired Ethernet on Ethernet action myself.
    The inter-specification is my favorite, I like with a male Cat 6 cable in a female Cat 5 plug....

  19. On the next iSCSI: Linux - Killer! by JoshDM · · Score: 1

    Next week, Horatio and the team are called in to investigate when a relatively unknown l33t hax0r is murdered at a hip Miami internet cafe. It turns out he was an investigative aide working for Comcast and was monitoring bandwidth usage. As Horatio interviews the cafe's owner, another patron sneaks out of the cafe and crashes his RAID while installing Debian. However, the case gets more complicated when they discover another murdered victim inside the server.

  20. Re:Not an iSCSI killer, here are the reasons why n by pe1chl · · Score: 1

    It may be cool, but it is WAY too expensive. 4000 dollars for a 15-disk box without disks, come on!

    I am looking for an affordable storage box for my home network, but for this kind of money I expect SMB/NFS functionality, not a dumb ATA interface over ethernet.

  21. Cheaper? by KillerEggRoll · · Score: 1
    "That's just fine with UCAR's Frederick. He installed a separate network on servers that connect to the Coraid backup device."
    How is AoE cheaper? If you care about your storage infrastructure, then be prepared to spend some money and effort (dedicated SAN networks are always good!). If they want to penny pinch, then use software-based intiators and targets. The target software will generally let you us any type of disk storage regardless of its native interface (ATA, SATA, SCSI, FC, they're all good!). If performance is an issue, forgo the expensive TOE NICs and use normal gigabit NICs. Setup the NIC driver so that interrupt coalescing is disabled and use >=9000 MTU ethernet frames. Be prepared to pay the price with extra CPU cycles though...
  22. Re:Not an iSCSI killer, here are the reasons why n by Gaima · · Score: 1

    While I'm not especially interested in network storage, and I know very little about SANs and AoE, I still thought I'd give my input.

    1) The "server", or drive array, handles the RAID, and all space carving (LVM, EVMS). AoE tools then export block devices.

    2) Yup, no argument there.

    3) VMs can boot from AoE, unless you use RedHat in which case it's not stable.

    4) Multipath ethernet (or bonding) can be done trivially at the kernel level on all connected devices. Both to double the throughput, or just increase the reliability.

    This is perhaps a poor comparision, but AoE is somewhat akin to Linux, as a SAN is to MS Windows.
    AoE is a very important part, but a kernel is just a kernel.
    SAN is a whole system, complete with GUIs, and reports.

    Will it kill iSCSI, who knows, I don't, but I don't care.

  23. Bare boards? by bhima · · Score: 1

    I'd be far more interested in AoE and iSCSI if I could buy a few bare bridge boards to retrofit some RAID cages I have now.

    --
    Nothing in the world is more dangerous than sincere ignorance and conscientious stupidity.
  24. Re:Not an iSCSI killer, here are the reasons why n by dfghjk · · Score: 1

    while I agree with you, the issue of multipath is moot. Any device with only one port has that port as a single point of failure. You solve that problem with two ports and redundant switches. It is no different for SAN's, iSCSI or FC.

    SAN's management capability is also it's downfall. Expensive, complicated and vendor-specific.

  25. Re:Not an iSCSI killer, here are the reasons why n by cblack · · Score: 1

    I read some of the responses. First off, I still don't see how you can have multipath if the actual trays only have one port (which looks to be the case). Their EtherDrive units where a RAID card and drives sit in one unit and then the already-raided volumes are exported over AoE is a bit different, but at that point you could just make your own iSCSI target and be more compatible with existing mature iSCSI implementations (such as the software initiator in windows).
    All this talk of how raid /can/ be done on a linux server is missing my main point, which is: raid and volume management should not /have/ to be handled on the server in a SAN environment, it is one of the main selling points of SANs. A single place to manage your storage configuration, all servers just see a chunk of storage and don't have to worry about the details.
    I am not saying AoE is not useful in some settings or a neat technology, my main point is that it is not an iSCSI killer because it does not fill all the functions iSCSI does.

  26. I can't tell if this is clever or stupid... by YesIAmAScript · · Score: 2, Interesting

    A wise man once told me there is a fine line between them.

    ATA is a crappy protocol, even when local. It's only good for squeezing that last $0.03 out of the controller cost. Once you are using ethernet cables ($1) and links and PHYs on each end ($4 each), it makes a lot more sense to put some brains back in. Use SCSI. Heck, even ATAPI optical drives (the optical drive in your computer) uses ATAPI, which is SCSI in packetized ATA transfers.

    Also, I'm a bit nervous about the packet CRC validation being done in the ethernet controller/layer itself. The problem is that if an ethernet switch between you and the storage device stores packs and forwards them (as all smart switches do), it may also chose to regenerate the CRC on the way. If it corrupts the packet internally and generates a new, valid CRC for the new, corrupt packet, you have undetected corruption. I'd be a bit nervous about that for my hard drive.

    I do think using GigE is a smart way to attach hard drives to servers. I look at the back of an Apple XServe and see two GigE ports and a fibre channel card. Why can't one GigE port be used to attach to the network and one to the XServe RAID? Why do I need to get a multi hundred dollar card to attach to the XServe RAID when that GigE port is fast enough? It'd sure save a lot of cost, and hopefully reduce the price ot the end user.

    Anyway. I'm pro GigE attachment, not sure I'm for this AoE.

    --
    http://lkml.org/lkml/2005/8/20/95
    1. Re:I can't tell if this is clever or stupid... by dfghjk · · Score: 1

      ATA is a perfectly fine protocol for block storage and is much leaner that SCSI. The SCSI protocol was used for ATAPI because it already existed and was needed to support a wide variety of devices besides disk. It makes no sense to put your imaginary "brains" back in.

      I'm pretty confident that you can prevent unintended data corruption. TCP/IP manages it so there's your proof of concept :)

      GigE is not a good choice for disk attachment since it is easily outrun by a small number of disks. 10GigE is where it's at.

      Apple is not the end-all-be-all of server manufacturers.

    2. Re:I can't tell if this is clever or stupid... by Anonymous Coward · · Score: 0

      Why can't one GigE port be used to attach to the network and one to the XServe RAID?

      It can. If your needs are modest enough, iSCSI works fine. There are some third-party iSCSI solutions out the for the Mac.

      But the thing is, Fibre Channel just plain works better. It's a hell of a lot faster, for starters, which is a must if you're doing something like video. And if you want to do something like a SAN for shared server storage (think database servers, for instance) then the extra cost is really negligible.

      iSCSI has always struck me as a solution in search of a problem. Maybe that's just me.

  27. Re:Not an iSCSI killer, here are the reasons why n by cblack · · Score: 1

    Agreed on your multipath statements, except that in this case, due to the topology, losing a switch means losing all drives connected via that switch. In most SANs (sometimes even iSCSI) you have multiple routes from the raid card, through different networks, to the servers.

    As far as SAN's management capability being its downfall, I disagree. I find it isn't terribly complicated (much simpler/faster than the Linux LVM tools I've used) and it can even be done in a standard way by creating your own iSCSI target and using those very same LVM tools. Someone even commented on this story that they had done this. The point is that all the raid and volume administration is done in one place, and individual servers do not have to worry about that complexity.

  28. Ignoring many issues by Anonymous Coward · · Score: 0

    For small time users, I think this will catch on.

    But you can't ignore a lot of the issues that high end storage systems address that this doesn't.
    - Reliability
      - Availability
      - Smooth failure/degredation (when weird shit happens, how well does the device handle it, while maintaining uptime)
      - Mutli-path I/O
      - Cache writing. ATA has a notorious problem that drives cache and write things at their own will. However it's not on a level that the operating system is aware of, which make for some potential disasters when you use stuff in a transactional environment.
    - Performance
      - Response time (a lot of people ignore this one)
      - Throughput
    - TCO
      - How long do you spend fucking with a broken components?
      - How much money do you spend on replacing broken components?

    For home users and environments where the admin really has nothing but time, yeah, pretty good setup. But for enterprise environments where the company you're working for cannot afford for its storage setup to have high downtime, no way. Enterprise storage systems are still leagues ahead of home brew software solutions because they throw lots of money at R&D, not just time and community testing.

  29. Age of Umpires by astralbat · · Score: 1

    Got to love a good British parody... Age of Umpires :-)

  30. Not Routable? by stereoroid · · Score: 1

    If I'm reading the Wikipedia AoE article right... AoE is a L2 protocol that can not cross routers. That would immediately rule out the office I work in, in which floors and the data centre are on separate TCP/IP subnets. Small offices only, then?

    But, as noted above, if they are claiming that they avoid the cost of ToE NICs for iSCSI, that's a spurious claim, since they are an optional performance enhancer, not a requirement for iSCSI. I've seen surprisingly decent performance without them, with the HP EVA iSCSI bolt-on from QLogic and ordinary Broadcom server NICs.

    --
    (this is not a .sig)
    1. Re:Not Routable? by bunco · · Score: 1

      Yes and No.. you could set up a new office-wide LAN utilizing existing switching equipment (vlans + trunks). Depending on switch platform, cabling, etc, this could be quite easy. The trouble is dropping the AoE clients on the new LAN without pulling more cable. Not a problem in the node room.. but certainly a problem if you want to boot a bunch of desktops residing in each cube (IMO, AoE isn't well suited for this).

      You'll find that most people who leverage this type of technology will use a dedicated gigE NIC in each client and build a separate LAN solely for storage. So in many cases, the ability to retrofit is of little concern.

    2. Re:Not Routable? by Anonymous Coward · · Score: 0

      Haven't read all the remarks but you would not want a whole office connecting to this directly.
      You would have it connected to a few servers, one of which could be a fileserver. The office workstations would then connect to the fileserver and do what it's suppose to.
      AoE is only a disk subsystem not a fileserver...

  31. What about vblade? by Mostly+a+lurker · · Score: 1
    I cannot imagine buying the Coraid devices: as others have mentioned, the savings over iSCSI are too small and you risk single vendor lock-in. However, I am intrigued by the possibilities provided by vblade. As I understand it, this module allows you to change a dirt cheap Linux machine into an AoE controller for regular ATA/SATA disks. This would not replace FC based SANs for latency critical applications, but could apparently provide a very nice, low-cost backup device.

    Does anyone here have experience with vblade? Is my understanding correct?

    1. Re:What about vblade? by pgfault · · Score: 1

      I just tested this last week. vblade installation was a snap. From there it's a matter of creating an empty file, associating a loopback device with it, and having vblade "export" it to the LAN. On another machine, load the aoe kernel module, install the aoe-tools, and run aoe-stat to see that the device is exported. You can then mount it and stick a filesystem on it from the remote machine. As a test, I started with ext3. Worked fine. Then I put OCFS2 on it to see if I could mount it read-write on 2 hosts. That worked too. All in all, I'm impressed. This should work well for backup, cheap HA, or Xen environments.

      The AoE tools, including vblade, can be found here.

  32. Re:Not an iSCSI killer, here are the reasons why n by Odinson · · Score: 1
    It's good that you mention multipath support. Have seens any docs out there on how to do a simple multipath setup with both Linux target and initiators? I tested iscsi about 8 months ago and found 0 docs on it.

    Thanks.

  33. Ultimate Proof by eno2001 · · Score: 1, Offtopic

    This thread in the iSCSI Killer story is ultimate proof that teenagers in their parent's basements all around the world have taken over Slashdot. In the days of yore, there would have been a lot of loud rejoicing at ATA over Ethernet. Today, nothing but a bunch of lame jokes based on gaming by high school drop outs. Yes, the days of Slashdot have come and gone. There is no hope.

    --
    -"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
  34. Re:Not an iSCSI killer, here are the reasons why n by swillden · · Score: 1

    It may be cool, but it is WAY too expensive. 4000 dollars for a 15-disk box without disks, come on!

    Have you prices rack-mountable boxes with space, airflow and power for that many drives? They cost clost to that much even without the AoE adapters.

    I am looking for an affordable storage box for my home network, but for this kind of money I expect SMB/NFS functionality, not a dumb ATA interface over ethernet.

    Coraid's stuff is obviously not for home use. For home use, use an old PC filled with disks. Add more PCs filled with disks as needed. Because AoE is dumb, you'll have to figure out how to set up RAID and volume management appropriate to your needs. OTOH, you can set it up so it does exactly what you need. Or, if you want to spend a little more money, do a little less work and have a little less flexibility, buy one of the standalone storage boxes that provide CIFS or NFS services.

    Personally, I have a home file server that is full of disks -- it actually has two more disks than places to mount them, so those two are sitting on the floor of the case. I'm thinking seriously about taking an old 500Mhz K6 I have sitting around and moving some drives to it (along with the ATA133 controller card they're connected to), then exporting them to the file server via AoE or iSCSI. I think I have another Gig-E card lying around.

    --
    Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  35. (-1, Get Off My Lawn) by Cid+Highwind · · Score: 1

    Yeah, instead of mildly amusing jokes about video games, there would have been a dozen poorly disguised goatse.cx links, some obscene ASCII art and references to Natalie Portman and hot grits. Anyone who misses the "good old days" of slashdot wasn't really there.

    --
    0 1 - just my two bits
    1. Re:(-1, Get Off My Lawn) by eno2001 · · Score: 1

      Hey... I hold the guys who posted hot gritz, natalie portman and goatse trolls in high regard. I was/am still among them. ;P You KNOW you liked it.

      --
      -"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
    2. Re:(-1, Get Off My Lawn) by DAldredge · · Score: 1

      I never got death threats or my address posted to /. by people who disagreed with me in the 'old days'

      I do miss them, the knowledge level of the typical /.er was higher.

    3. Re:(-1, Get Off My Lawn) by Anonymous Coward · · Score: 0

      Maybe in the 'old days' you weren't such an asshole!?

  36. iSCSI needs killing? by glwtta · · Score: 1

    Seriously, I don't think it needs any help whatsoever.

    --
    sic transit gloria mundi
  37. Re:Not an iSCSI killer, here are the reasons why n by dfghjk · · Score: 1

    yes, removing routing takes away that option but a fully redundant connection doesn't really need that. what it needs is fully independant paths and multiple routes aren't needed there.

    The holy grail of SAN's is unified SAN management and the number one complaint of SAN's is that management is too complicated and causes vendor lockin. No doubt that a centralized place for storage management is frequently desirable. If it weren't SANs would never exist in the first place.

  38. Re:Not an iSCSI killer, here are the reasons why n by eno2001 · · Score: 1

    I believe when they say "server", they mean the server that is hosting the drives and serving them to the network. So that DOES centralize all the management. You just serve out the logical volumes using AoE and you're all set.

    --
    -"...bad old ideas look confusingly fresh when they are packaged as technology" - Jaron Lanier (Digital Maoism on Edge.o
  39. I just deployed an AoE SAN by Tracy+Reed · · Score: 4, Informative

    AoE rocks. It is very easy to set up, way simpler than iSCSI or fibrechannel or any other SAN technology I have used. And it enabled us to have many more options for high availability or clustered filesystems (which we are not yet using but I have been following the progress of GFS and Lustre, learning towards Lustre). We did not buy the Coraid stuff but instead used vblade on our own disk machines. A disk node in our cluster has 4 300G SATA disks which we RAID 5, 512M RAM, and the cheapest CPU Intel currently makes. We have dual core Opterons with 4G of RAM each with no internal disk. They PXE boot and then mount root straight off the AoE. Then we run Xen on the Opteron boxes. This is the killer setup. We can migrate xen domains avoiding downtime for hardware maintenance and if a machines dies we can instantly restart it on another machine because it all runs off the AoE SAN.

    So far I am very pleased. Just make sure you get hardware that can do jumbo frames as this will increase your performance by 50%.

    1. Re:I just deployed an AoE SAN by saleenS281 · · Score: 1

      I'm sorry, but there's no way this should be insightful. Which part of implementing a fibre channel network did you have troubles with? Plugging it in? Or pressing the "scan fibre devices" button in your management app of choice? I don't believe for a second, after reading through all this, that AoE is any easier than FC or iSCSI.

    2. Re:I just deployed an AoE SAN by Tracy+Reed · · Score: 1

      How about configuring the Clariion disk arrays? We had to have a guy from EMC in for a whole day to do that. How about installing the fibrechannel HBA's and drivers? That was fun. How about configuring the fibrechannel switch? You have to learn how to fence off crashed or misbehaving hosts etc. Much easier to do with a switch where I already know how to turn off the switch port. I could go on... Ethernet expertise are far more plentiful than fibrechannel expertise.

    3. Re:I just deployed an AoE SAN by labratuk · · Score: 1
      We did not buy the Coraid stuff but instead used vblade on our own disk machines. A disk node in our cluster has 4 300G SATA disks

      What happens when one individual disk fails? Do you have to bring down the whole set of four drives to replace it?
      --
      Malike Bamiyi wanted my assistance.
    4. Re:I just deployed an AoE SAN by Tracy+Reed · · Score: 1

      Our disks are SATA hot swap disks in a 4 bay hot swap 1u case. So when a single disk fails I just pull it out and put in another one. No need to bring down the whole set of 4 disks. Linux's RAID support is pretty sweet. :)

    5. Re:I just deployed an AoE SAN by labratuk · · Score: 1

      Ah, ok. I didn't know libata's hotswap code was reliable yet.

      --
      Malike Bamiyi wanted my assistance.
    6. Re:I just deployed an AoE SAN by draziw · · Score: 1

      Config on the gear I work on (google fastest hpc storage): "lun add" and follow the options picking the size. Config 300+ TB at the same time - same about of work. Kick a user off? Can auto fence at the switch if you want to use one, or on the gear I work on "zoning edit" or "user edit". Forget some commands "help" spits 'em out. Or can always use the GUI. With the above, the storage shows up as nice SCSI disks - quite easy to work with.

      Cheers

    7. Re:I just deployed an AoE SAN by saleenS281 · · Score: 1

      Clarion: their configuration utility is point and click.

      HBA's: installation of drivers takes about 3 seconds, it should've been fun. Buy qlogic, it's ./qlinstall on linux, pkg_add on solaris, or a standard hardware install on windows. All of the above OS's also have built-in drivers if you're just too hard up to do the install.

      Fence off? It's called zoning, and again is point and click. It takes about 5 minutes.

      Please, do go on. AoE is a far bigger pain in the ass than FC, I work with both on a daily basis.

    8. Re:I just deployed an AoE SAN by jabuzz · · Score: 1

      The problem with AoE is it is exactly that ATA over Ethernet. So I am very limited to which drives I can attach, no 15K drives, no 10K drives bigger than 150GB, and certainly no tape drives. The routing is not at problem, as any decent highend switch/router will do layer 2 these days. For this to have been a killer application it should have been SoE, that is SCSI over Ethernet. That way I could use bigger and faster SCSI drives as well as tapes. The overhead of SCSI to ATA is minimal. Heck every Firewire drive/enclosure in existance does it.

  40. Re:Not an iSCSI killer, here are the reasons why n by Cyberax · · Score: 1

    Me too. I need ~5Tb storage for my film and music collection, but I can't find a good solution.

    Plain PC with Linux doesn't suit me because there are only 3 or 4 ATA controllers on a typical motherboard. Additional RAID controllers help but not much.

    AoE solution allows to install literally dozens of cheap disks in a cheap gigabit switch.

    Price on AoE should go down - electronics in AoE controller should cost no more than $20-$30.

  41. NBD and Raid1 by Cheeze · · Score: 1

    Why can't you just use an NBD server and client and setup software raid1?

    --
    Why read the article when I can just make up a snap judgement?
  42. it's better because it's simpler by Anonymous Coward · · Score: 0

    AoE just plugs into the network switch. SaMBa requires an installation, configuration, virusation, god-knows-what-else.

    A Fortune 500 company doesn't care, but 2 million small businesses and nonprofits just want plug and use. This is a BIG deal for us little guys. I hope it makes it to market, it'll be even better than the Linksys Slug.

  43. Please provide a vendor by Anonymous Coward · · Score: 0

    Please provide a vendor that offers this. How did you like their customer service also?

  44. In China a similar invention by phoebe · · Score: 1

    has been reported from Suntang (google cache), however it can be difficult to find out information from them as their website is almost always down and they never reply to email: office@suntang.com. They primarly install Linux based thin client systems around China, and have moved development over to supporting Windows and concepts like VDSA (the Virtual Disk System Architecture) and Virtual Hard Drive Technology.

    :(

    They manufacture some great looking thin clients.

  45. put it back in the oven by jhackworth · · Score: 2, Insightful

    perhaps an interesting idea, but just because I can build a computer out of old, recycled clock parts doesn't mean it is going to become my server. Also, iSCSI adoption has increased something like 40% this year. Windows support for iSCSI will improve dramatically with the next revision, and iSCSI costs are only going to decrease.

    Also, consider management of one of these AoE boxes. What sort of tools are out there to simplify provisioning, deployment, snapshots and backup, etc. In order for this to go anyplace but the basement of 'the IT guy at work' a whole lot more stuff will be required. Oh yeah, and that probably isn't going to happen with 1 vendor controlling the market.

    AoE is not fully baked yet. Put it back in the oven and let me know when the timer goes off.

  46. AoE works, and it is cheaper by MagicMerlin · · Score: 2, Informative

    we bought coraid devices, and they are AoE is much simpler (read: cheaper) than iSCSI. when using jumbo frame switches/cards, we were able to get transfer rates very near theoritical limits on gigibit links, something I have never seen on iSCSI or fc for that matter.

    the only thing that bothers me about AoE is there is only a single vendor supporting it at the moment. other than that, it is great stuff. while it is not routable in the sense ip is routable, you can do creative things with ethernet switches and vlan basically giving san like functionality at a fraction of the cost. no longer do you have to keep dual fc/cat6 infrastructure in your server farm.

    it's cheap, and if/when it supports bonding lines, well beat fc in performance (comparing two gigabit fc vs/ bonded gigabit ethernet).

    merlin

    1. Re:AoE works, and it is cheaper by smpierce · · Score: 1

      I couldn't agree with you more. I'm in the process of implementing a Coraid SR-1520 and have been amazed by the results so far. The ease of setup, the flexibility of the raid configuration not to mention the performance. After running some Bonnie++ tests, I was shocked to find out that my >$1 per GB box was out performing my much more expensive EMC Clariion CX500 by a substantial amount. And with the hotspare cabability .... Let's just say I was orignally going use this for disk based backups. Now I can see this expanding way beyond just backups.

  47. something cool about this by arabagast · · Score: 1

    .. is that the specs for the AOE protocol is so simple that you could probably make your own little testbed with some cheap microcontrollers and some ram for caching. It wouldn't be very fast, but it would be one cool project.

    --
    Doolittle : ...What is your one purpose in life?
    Bomb no.20 : To explode of course.
  48. Re:Not an iSCSI killer, here are the reasons why n by pe1chl · · Score: 1

    I do not need hot-swap capability. When I want to add or replace a drive I can just powerdown the unit.
    However, all solutions I have looked at (the Coraid included) have this useless (for me) feature.

    Currently I am looking at a 3E high 19" cabinet I have, to construct some disk mounting hardware (horizontal rails across top and bottom) and put a small board (ITX) in it. The thing can then run as a (Linux) server and export the disks as SMB or NFS instead of AoE, so they are directly accessible to my satellite receiver/recorder (Dreambox) as well. When going AoE I would have to do NFS->AoE in my normal PC.

    I want the whole thing as low-power as it can be. So, lowpower board, stopping the disks when not in use, automatic fan control. Ideally, when everything is idle it should consume 15-25W.
    I don't intend to use RAID because with the usual RAID schemes you always have to have all disks running. Separate volumes and some manual copying of important files to different places should do, in this case.

  49. what about the low-hanging fruit? by Yonder+Way · · Score: 1

    If I could go to Best Buy and get a 5.25" enclosure with an ethernet port on the back from Linksys or Netgear or their ilk, pop in my favorite SATA or IDE disk, and stick it on a private gigabit LAN this would be fantastic.

    Right now the cost of entry discourages experimentation. Having to buy a $3,000+ chassis plus all the drives is going to require funding that I have to fight for. If I can implement a proof of concept for under $500, I don't even need my manager to sign off on the expense. I can just do it and then show him "hey, this works, and if we buy this $3,000+ chassis and a bunch of drives, I can give you 5TB for a fraction of what we're paying now".

    This is how Linux caught on in the Enterprise. Start at the bottom, work your way up. It's a lot easier to encourage experimentation and tinkering if the cost of entry is under $100 for a single drive enclosure.

    Personally, I'd love to play with something like this at home for my MythTV setup and if it works introduce it at the office as an alternative for low cost / low performance / low redundancy / high capacity storage (yes, there are some great applications for this if you accept its limitations).

    1. Re:what about the low-hanging fruit? by pe1chl · · Score: 1

      Reading over this, probably USB2 or Firewire is a better solution. For you, and also for me.
      Single drive enclosures are as low as $20 and you can connect them to a hub. Support is in all interesting operating systems.

      Another solution is "Sata port expanders" which connect cabinets with several Sata drives to a single Sata port on a controller.
      However, Linux support for this technology is limited.

    2. Re:what about the low-hanging fruit? by Christopher+Cashell · · Score: 1

      You can build a proof of concept for under $500. There is an application out there called vblade[1], which is a virtual EtherDrive blade. Basically, it allows you to export a local block device as an ATA over Ethernet device. Turning your junker PC in the corner with a couple of extra disks in it into a ATAoE testbed.

      It's GPLed code, works with the new native kernel AoE support, and was even written by one of the Coraid guys.

      [1] One of the aoetools, available on sourceforge here.

      I've been playing with this on a spare machine in the test rack in our data center, and I have to admit, it is pretty slick. There's potential here for use in a number of areas.

      --
      Topher
    3. Re:what about the low-hanging fruit? by Anarchitect_in_oz · · Score: 1

      This might highlight that i'm a too much of a mac fanboy

      Can't firewire do this already?
      What with Firewire over IP, and IP over Firewire(one cable network)
      Can you take a standard Firewire controller wire it to an Ethernet plug and get it work.
      or is it limited to only being accessable to one computer?

      --
      "Call us when the New age is old enough to drink" Beck
    4. Re:what about the low-hanging fruit? by Anonymous Coward · · Score: 0

      Actually, you can do that. Or iSCSI for that matter:
      http://www.nslu2-linux.org/

  50. Re:Not an iSCSI killer, here are the reasons why n by Tracy+Reed · · Score: 1
    1) Complexity for RAID and volume management is not centralized and is pushed to individual hosts. One of the main benefits of SAN technology is that you can just carve out storage from a single interface and assign it to a server and the server simply sees it as a block device. With AoE each drive is addressed separately by the server, which means it is up to the server (and server admin) to figure out how to handle distributing over multiple drives, handle drive failures, and expanding volumes. This is huge.


    AoE is a SAN technology and it is no different from other SAN technologies in this regard. AoE just provides a block device. Just like Fibrechannel or iSCSI or any other SAN technology. If you want RAID and volume management centralized instead of being pushed to individual hosts do what the Fibrechannel guys (and everyone else) does: Attach all of the disk to one host and use that host to aggregate it and manage it and export it to the rest of your clients. Even in the big Clariion disk systems from EMC and other SAN products they contain an internal PC which aggregates all of the disk for presentation to other hosts on the SAN.


    2) It is not a standard and is only really supported by one vendor. This may change in the future but it is significant right now. It is registered with the IEEE but that hardly makes it a peer-reviewed standard with input/improvements from many experts.


    It is a spec released to the public without strings attached. GPL'd implementations of both target and initiators exist. Lots of people have looked it over to the extent that it has even been included in the stable Linux kernel.


    3) No boot from SAN. Until someone makes some sort of mini bootstrap system on a CD or a hardware card implementation of AoE that can be addressed as a block device admins will be unable to host the root filesystem and/or C: drive on an AoE SAN


    Uh...I have a number of machines in a rack right across the hall from me which do indeed boot from SAN. All you need to do is tftp an initrd containing the AoE driver and boot with that.


    4) No multipath (that I can see). Perhaps I misunderstand this, but it seems like there is no way to do multipath IO with this system. That is, all the drives are single-connected to a network. If that network switch goes down, all drives on that network are inaccessible.


    How is this any different from fibrechannel? IIRC fibrechannel disks have a single connection also. What most systems do is mirror or RAID them. What I have done is I have made a mirrored pair of AoE disks on different switches and use Linux's md driver to mirror them.


    So AoE looks like a neat technology for pushing drives out of the box and potentially sharing them among hosts, but there is no intelligence there. It is just dumb block addressable storage with no added availability or management, and therefore is far from being an iSCSI or FC killer.


    Fibrechannel or iSCSI by themselves are just dumb block addressable storage also. The management layer generally has little to do with the technology that implements the block layer.
  51. question by RelliK · · Score: 1

    Hey, thanks for the info. Looks like promise has the same enclosure with FC and plain SCSI ports. What are the advantages/disatvantages of iSCSI, FC, and plain SCSI? I am specifically wondering about M500i, M500f, and M500p? Seems like they all have the same features, but plain SCSI is faster.

    --
    ___
    If you think big enough, you'll never have to do it.
  52. unintended corruption... by YesIAmAScript · · Score: 1

    I'm pretty confident that you can prevent unintended data corruption. TCP/IP manages it so there's your proof of concept :)

    Did you read the article?

    The article explains how AoE is much better because it's much cheaper because you don't need to calculate all those checksums like TCP/IP does. It says just rely on the link layer checksums (note - they aren't checksums, they are CRCs).

    I agree you can manage unintended data corruption at higher layers. iSCSI does this. And it's pretty much my entire point. That you should do so and AoE doesn't.

    This protocol seems to cheap out in ways that don't make sense.

    ATA is not a perfectly fine protocol for block storage. It works, true. But it's far from optimal. Its methods of handling error signalling is poor. Its methods of handling delayed error signalling is very poor.

    I think the idea of using ATA and all its cruft to save a couple pennies on a big-tyme storage system doesn't make sense to me. If I can buy an optical drive for $30 that has SCSI (ATAPI) in it, I think the benefits of SCSI can be affordably brought to a large storage system too.

    --
    http://lkml.org/lkml/2005/8/20/95
    1. Re:unintended corruption... by dfghjk · · Score: 1

      "Did you read the article?"

      Yes I did but only recently. It was dead earlier. If the claim is that hardware will solve that for you then I don't know. Any solution that mostly works is broken, especially for storage. Unfortunately not all agree :(

      "ATA is not a perfectly fine protocol for block storage. It works, true. But it's far from optimal. Its methods of handling error signalling is poor. Its methods of handling delayed error signalling is very poor."

      In what way? Are you confusing it with SCSI error handling and its contingent allegiance conditions? Talk about bullshit! Never, ever, EVER had a problem dealing with ATA error handling. Besides, that's all subject to reimplementation with a new physical layer.

      "I think the idea of using ATA and all its cruft to save a couple pennies on a big-tyme storage system doesn't make sense to me. If I can buy an optical drive for $30 that has SCSI (ATAPI) in it, I think the benefits of SCSI can be affordably brought to a large storage system too."

      Again, what cruft? SCSI has 1000x the cruft of ATA. Have you ever programmed either of these devices? The purpose of using ATA here is that the command set is ENTIRELY adequate for disks and it's much leaner than the bloated SCSI command set.

  53. Not an iSCSI killer by poopie · · Score: 1

    iSCSI has a whole bunch of things going for it -- it allows sharing SAN storage over ethernet on the WAN, it lowers the cost of SAN clustering. It works on existing NAS storage that supports iSCSI, it works with SAN storage with a FC to ethernet switch like the Cisco MDS 9000

    ATA over ethernet doesn't work on enterprise NAS or SAN storage. ATA over ethernet doesn't provide any redundany or fault tolerance without hardware RAID on storage or software RAID on the client.

    ATA over ethernet also is not available for a wide variety of guest OS platforms, whereas iSCSI currently is available for many OSes.

  54. Sounds neat by maxrate · · Score: 1
    Sounds neat - everything said, I'm still very suspicious about the latency. I agree iScsi and other technologies are a little over priced. I think the best solution is optically coupled drives on a high-density controller board. You can actually have the drives remote from the server, but they act local. Imagine keeping half your hard disks in one side of the building and half on another side of a building!? That would definately help with redundancy (different power supplies) and physical seperation (flood, fire, theft) etc!

    Very good thinking otherwise.

  55. guest platforms - whaddawant? Amiga? by JimmytheGeek · · Score: 1

    It's supported in the linux kernel. I don't know about the bsd's or OSX, and there's a commercial driver for Windows.

  56. Re:Not an iSCSI killer, here are the reasons why n by GoRK · · Score: 1
    You also can boot from SAN, it's not a problem. Just add required modules and configs to initrd and place it on a USB drive.


    As a point of contention, that is booting from USB and running the root filesystem over AoE, which isn't quite the same thing. You could also do a PXE, CD-ROM, Floppy, or HDD boot and use the AoE block device to the same result. Booting from a device means that the bootstrap is loaded from the device itself. Currently AoE can't do that and even if you created an HBA for AoE, it would still put the intelligence of where to load the bootstrap from in the client. The solution would be to add some sort of redundant, intelligent proxy to the mix (which you can actually do -- they sell one) but then you are no longer cost-comptitive against iSCSI and low-end FC.
  57. I like it. by jwiegley · · Score: 1

    So I saw AoE about a month ago and I started a graduate thesis project for analyzing and specifying different mail server architectures for my institution. The institution currently has 330Gig of mail storage and complains that this is too much usage when somebody complains their quota is too small.

    I don't have the bucks to buy a terabyte of storage to prove them wrong but I do have a lab with 16 computers. So we recently ran the vblade servers on 10 of the machines and exported a 130Gig partition from each machine. Then we took one of the other machines to use as a file server. It builds a RAID6 /dev/md0 out of the 10 exported /dev/etherd/eX.Y devices and then exports /dev/md0 via NFS (currently). The result is a terabyte mail storage that can suffer the loss of any two vblade machines (loss of the single NFS server and central ethernet switch is still a problem.)

    How well does it work? Well we just set it up so results aren't conclusive but bonnie results show the various disk operations to the /dev/md0 device is almost identical to a raw local partition. Nice.

    An iSCSI killer? no, different purposes. But AoE is excellent and has it's place. A very good place.

    --
    I will never live for sake of another man, nor ask another man to live for mine.
  58. AoE by jspiers · · Score: 1

    If you're interested in an industry perspective, I'm the CTO at an iSCSI SAN provider. Marketing fluff has been left out, leaving my two cents on AoE as I understand the technology. TCP is a universally accepted transport that guarantees data delivery over any Quality of Service, along with many optimizations that switch and network accelerators use to optimize its performance on lossy networks. AoE will not work over lossy networks, therefore it's not a solution outside the data center (i.e. campus SANs or Remote Copy). iSCSI has a built-in security model with IPSEC and CHAP. AoE SANs must be secured at the switch level, which introduces more management complexity with having to setup VLANs or other features on the switch, which may also require the purchase of higher cost Ethernet switches. If the switch is compromised the storage is completely exposed. An encryption and authentication model is also missing. AoE doesn't support IP addressing & management. There is a compelling business case for IP convergence. IP offers one technology and management framework for the Internet, VOIP & iSCSI/Storage and the rest of the IT infrastructure. This being said, AoE isn't all bad but it's not an iSCSI killer. It could offer a cost effect storage solution for small businesses or home offices. John Spiers

    1. Re:AoE by Anonymous Coward · · Score: 0

      Oh and Bill Gates says linux sucks.

    2. Re:AoE by Anonymous Coward · · Score: 0

      AoE does have packet retransmission, but if you must use it across routers and over lossy networks, why not tunnel it through ssh? Problem solved. Why does everything have to be inside AoE, which is really just a minimal wrapper for disk commands? Whatever happened to modularity?

  59. I've been doing this kind of thing for a long time by Anonymous Coward · · Score: 0


    I've been doing this kind of thing for a long time.

    Using VMWare, I can set up a virtual IDE hard disk that is mapped to a file that resides on a network-mounted filesystem.

  60. Re:Not an iSCSI killer, here are the reasons why n by complete+loony · · Score: 1
    AoE is just a disk wire interface. It greatly expands the number of disks a single machine (or cluster) can directly access. It should also be possible to produce a cheap hardware chipset, and this might even happen if there were some more compitition.

    Once you've mounted all these disks, you could even provide an iSCSI interface to network clients.

    Personally I'm waiting for a cheap USB style enclosure. What could really nail this in the home market is some kind of clustering filesystem for windows, allowing multiple hosts to read and write to cheap network attached storage.

    --
    09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
  61. Myth of The Elder Days by Cid+Highwind · · Score: 1

    Yes, they were funny a lot of the time. My point was just that there was never a golden age where everyone was mature all the time and only posted on-topic, well-reasoned, polite comments.

    --
    0 1 - just my two bits
  62. TCP/IP vs. UDP/IP or raw IP vs raw Ethernet by billstewart · · Score: 1
    Sure, TCP's a lot of work, especially for 10Gbps - it's keeping track of sequence numbers, ACKing packets, detecting lost packets and retransmitting, checking timing to know the expected RTT, things like that. But you don't need to do TCP to get the benefits of IP. UDP is a lot less work - basically it's a protocol identifier layer and some optional checksumming. You could even skip the UDP layer and run the application as a protocol over raw IP, saving a few bytes at the expense of cluttering up the IP protocol numbering space.

    But IP is very little work for the average host - there's some initial handshaking to find out which network connector to use and what MAC address to put on the Ethernet packets, and if you're using a protocol stack there's a handoff from the Ethernet handler to the IP handler. Routers may have to do a lot of work deciding where to route packets, but hosts usually just slap a MAC address on each packet and hand it out the single Ethernet port. You're not going to waste much time, and in return you get several benefits

    • Your application is routable, so you can use it from anywhere on the Internet.
    • If you've got a big campus LAN, and want to put the server somewhere across campus, you're free to use routers instead of being required to use VLANs.
    • You can still use VLANs if you prefer.
    • You can use a single Ethernet port on your client machines if you need to.
    • Sniffers and similar network tools will have an easier time telling you what's on your net.
    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
    1. Re:TCP/IP vs. UDP/IP or raw IP vs raw Ethernet by dfghjk · · Score: 1

      I'd be interested to know why they didn't use UDP as well. I don't think routing was a priority or even desirable for them, right or wrong.

  63. Hot swap by CustomDesigned · · Score: 1

    SATA hot swap is a lot cheaper than SCSI hot swap. The SATA drives are probably hot swappable. I've also seen ATA hot swap drive carriers that are fairly inexpensive. SATA hot swap is a lot simpler than SCSI on the software front - there is no need to suspend activity on the entire SCSI bus during removal/insertion. Just unmount the drive/partitions in question, and replace away.

  64. All your base are... by Anonymous Coward · · Score: 0

    ...belong to them

  65. Rather than fork $4k for a disk chassis... by Ayanami+Rei · · Score: 1

    'tis better to leverage the protocol across a cluster of machines.
    Dedicate one or two disks and a GB port per blade and isolate it to a VLAN.
    Use AoE to expose the disks as a remote aggregation target or for a cluster aware FS.
    (I recommend partitioning them and using 60-70% for a cluster FS and the latter 30-40% for emulating networked tape drives for backups).

    --
    THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
  66. Venturcom BXP by jetmarc · · Score: 1

    > If you really want a diskless system now

    There exists a solution for diskless Windows XP stations. It is called "Venturcom BXP" and consists of server software and client drivers.

    The server installs on WinXP or Win2K3. You also need DHCP, BOOTP/PXE and TFTP servers. BXP includes them if you don't have them already in your LAN.

    The client drivers link to the NIC drivers and also include a tiny status tool and the disk-copy program.

    After installation, you create a virtual disk on the server and assign it to a client. Once the client boots, this disk appears as additional driveletter. Using the disk-copy program, you copy your system partition over to the virtual disk. Then you change the server configuration to instruct the client to boot from the virtual disk.

    At this point, the physical harddrive will appear as additional driveletter, while the virtual disk becomes C:\. You can remove the physical harddrive now if you want, or you can assign the windows pagefile to it for faster operation.

    With 100mbit ethernet you can achieve about 8-9 MB/s virtual disk performance. However, ethernet has considerable latency, and a BXP'ed machine doesn't feel as snappy as a real one.

    A nice extra feature is the possibility to "write-lock" the virtual disk. That is, all changes made to it can be stored in a separate file, which is deleted when the client is shutdown. Using this feature, the client always boots the same state. This is perfect for classrooms or webcafes where users may modify the configuration, delete system files, or infect the machine with trojans or viruses. All changes are magically undone when rebooting.

    It is also possible to assign such a "locked" image to several clients at once (the virtual disk is accessed read-only, and each client gets an individual temporary write-cache for its session). Using this feature you can install and customize one box, and then boot the image on a dozen boxes. For this to work, it is necessary that all clients have identical hardware (down to the PCI card order!).

    Other advantages are that the virtual disk is just a file. This provides for easier backup or versioning / branching. Using tools to snapshop the server partition, you can even backup the client while it's running.

    You can also use BXP to test-install software. Games for example can't be tested in VMware (lack of virtual 3D hardware). With BXP you can, because only the harddrive is virtual - the box remains physical!

    Marc

  67. I've programmed both... by YesIAmAScript · · Score: 1

    No, SCSI doesn't have 1000x the cruft of ATA.

    ATA has at least 3 ways of even specifying a block. CHS, LBA and LBA48. SCSI has 1.

    ATA has 10 ways of reading data, not counting the ATAPI (SCSI) ways and the Compact Flash ways.

    READ DMA
    READ DMA EXT
    READ DMA QUEUED
    READ DMA QUEUED EXT
    READ MULTIPLE
    READ MULTIPLE EXT
    READ SECTORS
    READ SECTORS EXT
    READ VERIFY SECTORS
    READ VERIFY SECTORS EXT

    SCSI has 4.

    Which has more cruft here?

    So, if you've never had a problem dealing with ATA errors, let me ask: How do you deal with errors on ATA write-behinds? Do you even know how the drive signals them? If so, how do you detect them and handle them? I know it can be done, but it's wedged into ATA rather poorly.

    ATA error handling isn't reimplemented with a new physical layer. SATA (for example) just serializes the data that was already sent over ATA. It still has all the DRQ bit stuff. Error handling is actually in the physical layer in ATA, but since they made it appear in the command registers, it has to be implemented at higher layers now and is not subject to redesign with new physical layers.

    As to ATA being leaner, did I forget to mention it has 2.5x as many read commands as SCSI? 3.3x as many mandatory ones?

    --
    http://lkml.org/lkml/2005/8/20/95
  68. Re: Other things by Crazy+Eight · · Score: 1

    Preserve Our Essence.