Sun Adding Flash Storage to Most of Its Servers 113
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."
Re:Lifespan? (Score:5, Informative)
Re:Samsung 256GB Flash Drive (Score:2, Informative)
IOPS (Score:5, Informative)
From what I've been able to discern this is actually true only in read-mostly applications and applications where writes are already in neat multiples of the flash erase block size.
If you're doing random small writes your performance is likely to be miserable, because you'll need to erase blocks of flash much larger than the data actually being changed, then rewrite the block with the changed data.
Some apps, like databases, might not care about this if you're able to get their page size to match or exceed that of the underlying storage medium. Whether or not this is possible depends on the database.
For some other uses a log-oriented file system might help, but those have their own issues.
In general, though, flash storage currently only seems to be exciting for random read-mostly applications, which get a revolting performance boost so long as the blocks being written are small enough and scattered enough. For larger contiguous reads hard disks still leave flash in the dust because of their vastly superior raw throughput.
Vendors, however, make a much larger margin on flash disk sales.
This article (PDF) may be of interest:
Understanding Flash SSD performance [managedflash.com]
(google text version) [209.85.173.104].
Re:We are going to have two layers of storage (Score:5, Informative)
Also, throw in wear-leveling and spare sectors. a million writes to a file system sector doesn't mean a million writes to a particular physical sector (could be 1000 writes each to a 1000 different sectors) and when a sector does wear out, it simply gets put out of service and is replaced with a spare one. this same principle is used in mechanical hard drives. if a sector is problematic to read from/write to, it gets marked as bad and the file system sector is remapped to somewhere else.
SSDs could quite likely last longer than mechanical hard drives in this regard.
Re:We are going to have two layers of storage (Score:5, Informative)
SSDs really shine for OLTP databases. Lots of random IO occurs on these databases (as opposed to data warehouses that use lots of sequential IO).
Normal hard drives are horrible for random IO because of mechanical limitations. Think about trying to switch tracks on a record player thousands of times per second; this is whats happening inside a hard drive (under a random IO load). Its amazing mechanical HDDs work as well as they do.
Re:I'm surprised that it is big enough to talk abo (Score:5, Informative)
You have no idea what you are talking about. Sun customers demand that the product Sun sells them have known reliability properties and that Sun guarantees their products properly interact with each other. It takes a significant amount of resources to do this validation. At the same time SSDs and HDDs react very differently to load and can have all sorts of side effects if the OS/application is not prepared to deal with them.
Re:I'm surprised that it is big enough to talk abo (Score:3, Informative)
Re:Samsung 256GB Flash Drive (Score:1, Informative)
Re:We are going to have two layers of storage (Score:5, Informative)
Five years ago, I would have agreed. These days, some of the better flash parts are rated as high as a million write cycles. If we're talking about 4 GB of flash, a million write cycles on every block would take a decade of continuous writes at 10 megabytes per second. Real-world workflows obviously won't hit the cache nearly that hard unless your OS has a completely worthless RAM-based write caching algorithm.... Odds are, the computer will wear out and be replaced long before the flash fails. That said, in the event of a flash write failure, you can always spin up the drive and do things the old-fashioned way. And, of course, assuming you put this on a card inside the machine, if it does fail, you wouldn't have to replace the whole motherboard to fix the problem.
That said, to reduce thrashing of the write cache, it might be a good idea to add a cap of a meg or two and spin up the hard drive asynchronously once the write cache size exceed that limit. Continue writing to the flash to avoid causing user delays while the HD spins up (huge perceived user performance win there, too) and flush once the drive is up to speed.
You could also do smart caching of ephemeral data (e.g. anything in /tmp, /var/tmp, etc.). Instead of flushing changes those files to disk on close, wait to flush them until there's no room for them in the RAM buffer cache, and then flush them to the flash. After all, those directories get wiped on reboot anyway, so if the computer crashes, there's no advantage to having flushed anything in those directories to disk....
BTW, in the last week, I've lost two hard drives, both less than a year old. I'm not too impressed with the write lifetimes of Winchester disk mechanisms. :-)