Slashdot Mirror


Sun Adding Flash Storage to Most of Its Servers

BobB-nw writes "Sun will release a 32GB flash storage drive this year and make flash storage an option for nearly every server the vendor produces, Sun officials are announcing Wednesday. Like EMC, Sun is predicting big things for flash. While flash storage is far more expensive than disk on a per-gigabyte basis, Sun argues that flash is cheaper for high-performance applications that rely on fast I/O Operations Per Second speeds."

9 of 113 comments (clear)

  1. Write cycles. again. by Amiga+Lover · · Score: 4, Insightful

    Cue up 20 comments going "But what about the limited write cycles, these things will fail in a month" and 500 comments replying "this is no longer an issue n00b"

    1. Re:Write cycles. again. by morgan_greywolf · · Score: 4, Insightful

      You forgot the 1000 comments prognosticating about SSDs replacing HDDs permanently "any day now" with the added bravado of saying "I knew this would happen! See, I told you!" with 3000 comments replying 'Yeah, but price/performance!", all of which will be replied to with "but price/performance doesn't matter, n00b. Price makes no difference to anyone."

      Then, in a fit of wisdom, a few posters, all of whom will be modded down as flamebait, will say "There's room for both and price/performance does matter, at least for now."

  2. Good by brock+bitumen · · Score: 3, Insightful

    They are trying to push new technology on their high paying customers because they can get a premium since it's a scarce resource, this will drive up production, and down the costs, and soon we'll all be toting massive flash disks all the day

    I, for one, welcome our new flash disk overlords

  3. Two layers, but not those ones by clawsoon · · Score: 5, Insightful
    We are going to have two layers, but they'll be deeper in the filesystem than that.

    High frequency, low volume operations - metadata journalling, certain database transactions - will go to flash, and low frequency, high volume operations - file transfers, bulk data moves - will go to regular hard drives. SSDs aren't yet all that much faster for bulk data moving, so it makes the most economic sense to put them where they're most needed: Where the IOPs are.

    Back in the day, a single high-performance SCSI drive would sometimes play the same role for a big, cheap, slow array. Then, as now, you'd pay the premium price for the smallest amount of high-IOPs storage that you could get away with.

  4. Re:Samsung 256GB Flash Drive by Archangel+Michael · · Score: 3, Insightful

    Also, their "thumper" server has 48 drives in it. Would you want to pay around $1000 per drive to fill that up? Yes. If performance dictated it was necessary.

    Just because you don't want to, doesn't mean everyone else doesn't want to also.
    --
    Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
  5. Re:I'm surprised that it is big enough to talk abo by gbjbaanb · · Score: 4, Insightful

    "Adding a flash storage option" is pretty much an engineering nonevent but as a marketing event its a magnificent and almost unbelievable paradigm-shift approach to a massive problem that's been crying out for a reliable storage-based performance solution for years.
  6. RAID 4, anyone? by mentaldrano · · Score: 3, Insightful

    In the time between now and when SSD becomes cheaper than magnetic storage, might we see a resurgence of RAID 4? RAID 4 stripes data across several disks, but stores parity information all on one disk, rather than distributing the parity bits like RAID 5.

    This has benefits for workloads that issue many small randomly located reads and writes: if the requested data size is smaller than the block size, a single disk can service the request. The other disks can independently service other requests, leading to much higher random access bandwidth (though it doesn't help latency).

      One of the side effects of this is that the parity disk must be much faster than the data disks, since it must service all requests, to provide the parity info. Here SSD shines, with its quick random access times, but poor sequential performance. Interesting, no?

  7. Cheaper than RAM? by AmiMoJo · · Score: 3, Insightful

    At the moment high performance SSDs are still more expensive than RAM. Since a 64 bit processor can address vast amounts of RAM, wouldn't it be even better and cheaper just to have 200GB of RAM rather than 200GB of SSD?

    Okay, you would still need a HDD for backing store, but in many server applications involving databases (high performance dynamic web servers for example) a normal RAID can cope with the writes - it's the random reads accessing the DB that cause the bottleneck. Having 200GB of database in RAM with HDDs for backing store would surely be higher performance than SSD.

    For things where writes matter like financial transactions, would you want to rely on SSD anyway? Presumably banks have lots of redundancy and multiple storage/backup devices anyway, meaning each transaction is limited by the speed of the slowest storage device.

    --
    const int one = 65536; (Silvermoon, Texture.cs)
    SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
  8. Re:We are going to have two layers of storage by dgatwood · · Score: 4, Insightful

    Because write caches in RAM go away when your computer crashes, the power fails, etc. Battery-backed RAM is an option, but is a lot harder to get right than a USB flash part connected to an internal USB connector on a motherboard.... In-memory write caching (without battery backup) for more than a handful of seconds (to avoid writing files that are created and immediately deleted) is a very, very bad idea. There's a reason that no OS keeps data in a write cache for more than about 30 seconds (and even that is about five times too long, IMHO).

    Write caching is the only way you can avoid constantly spinning up the disk. We already have lots of read caching, so no amount of improvement to read caching is likely to improve things that dramatically over what we have already.

    Even for read caching, however, there are advantages to having hot block caches that are persistent across reboots, power failures, crashes, etc. (provided that your filesystem format provides a last modified date at the volume level so you can dispose of any read caches if someone pulls the drive, modifies it with a different computer, and puts the drive back). Think of it as basically prewarming the in-memory cache, but without the performance impact....

    --

    Check out my sci-fi/humor trilogy at PatriotsBooks.