Superfast SSDs are coming, but will they be used the right way?(arstechnica.com)
arstechnica.com
Superfast SSDs are coming, but will they be used the right way?
http://arstechnica.com/business/news/2010/10/super-fast-ssds-are-coming-but-will-they-be-used-the-right-way.ars
12 comments
> operating systems need to support SSD's as a cache for the main hard drive rather than as a hard drive themselves
No need to update your OS if you buy the Seagate Momentus XT hybrid SSD/platter drive (now $110 for 500 GB on Amazon) as the drive will do this itself for any OS. The SSD part of the drive acts as a transparent read-through cache. I bought this for my Thinkpad and am very happy w/ the performance.
No need to update your OS if you buy the Seagate Momentus XT hybrid SSD/platter drive (now $110 for 500 GB on Amazon) as the drive will do this itself for any OS. The SSD part of the drive acts as a transparent read-through cache. I bought this for my Thinkpad and am very happy w/ the performance.
Personally, that's the approach I'd prefer, because then all my data is on the drive, which I can take out of the system when the power supply fails, to recover my data. If the OS has silently migrated some of my data onto an invisible chunk of flash, I can't recover without that flash.
(If the OS is just using the flash as a cache, OK, but why? It's slower and more expensive than RAM.)
(If the OS is just using the flash as a cache, OK, but why? It's slower and more expensive than RAM.)
The only operating system that moves fast enough to add support for [flash caching] in that sort of timeframe is Linux...
Solaris already has L2ARC, Vista had ReadyWhatever, and arguably if Apple had started working on it in 2006/7 (and hadn't been distracted by iOS) the feature would be done by now. But yeah, it looks like a lot of flash caching code is coming to market too late to do any good for desktop/laptop users.
Solaris already has L2ARC, Vista had ReadyWhatever, and arguably if Apple had started working on it in 2006/7 (and hadn't been distracted by iOS) the feature would be done by now. But yeah, it looks like a lot of flash caching code is coming to market too late to do any good for desktop/laptop users.
[deleted]
>The only operating system that moves fast enough to add support for something like this in that sort of timeframe is Linux
http://en.wikipedia.org/wiki/ReadyBoost
The ars article isn't very clear, however it isn't talking about a system having a magnetic hard drive and a flash hard drive (in a standard 2.5/3.5 fashion), but rather a magnetic disk and some sort of built-in or extension flash memory. There are new upcoming motherboards that have a decent amount of onboard flash memory for precisely this usage model.
In the SAN market there is a raging trend called Easy Tiering, FAST, or whatever other marketing glop the vendor makes. It allows you to have a couple of SSDs, and then lots of magnetic disks, finding a sweet spot between volume and speed as it automatically moves hot spots to the SSDs. It's a perfect use of varying speed technologies.
The new hybrid hard drives bring this -- to some success -- to the consumer market. They just need a lot more flash and a better algorithm and it's a killer solution: A 2TB magnetic disk with 32GB of high speed flash would be incredible.
http://en.wikipedia.org/wiki/ReadyBoost
The ars article isn't very clear, however it isn't talking about a system having a magnetic hard drive and a flash hard drive (in a standard 2.5/3.5 fashion), but rather a magnetic disk and some sort of built-in or extension flash memory. There are new upcoming motherboards that have a decent amount of onboard flash memory for precisely this usage model.
In the SAN market there is a raging trend called Easy Tiering, FAST, or whatever other marketing glop the vendor makes. It allows you to have a couple of SSDs, and then lots of magnetic disks, finding a sweet spot between volume and speed as it automatically moves hot spots to the SSDs. It's a perfect use of varying speed technologies.
The new hybrid hard drives bring this -- to some success -- to the consumer market. They just need a lot more flash and a better algorithm and it's a killer solution: A 2TB magnetic disk with 32GB of high speed flash would be incredible.
What is ReadyBoost? I'm having a hard time finding information about it where the writer seems to know what he's talking about, but it just looks like an extension of Windows's application pre-loading feature. That's nice, but not really the same as a real read/write cache.
Essentially the pagefile.sys (which at a high level is a massive memory mapped file that Windows uses for virtual memory) gets stored on a flash drive. It very much helps the overall responsiveness of a computer that doesn't have enough RAM to do without a pagefile.sys -- especially if they have a slow hard drive (I inadvertently installed Vista on a slow computer and this helped quite a bit).
ReadyBoost is different from PreFetch (they are features you can turn off/on independent of each other) which I believe you are referring to when you mention "pre-loading". The wikipedia article is decent: http://en.wikipedia.org/wiki/ReadyBoost
ReadyBoost is different from PreFetch (they are features you can turn off/on independent of each other) which I believe you are referring to when you mention "pre-loading". The wikipedia article is decent: http://en.wikipedia.org/wiki/ReadyBoost
You have to remember that the focus is about moving past old hard drive connections like SATA, so even if you got one of the new hybrid hard drives with flash on them, you would be limited by the SATA port it was connected to.
That is why all those companies are moving to PCIe directly, for the extra speed. If the OS were to handle caching and other things so the user didn't have to worry about it, then the experience would be much greater and faster all said.
That is why all those companies are moving to PCIe directly, for the extra speed. If the OS were to handle caching and other things so the user didn't have to worry about it, then the experience would be much greater and faster all said.
The gross throughput factor is hugely oversold for the vast majority of uses: In most scenarios IOPS is Godzilla to throughput's mouse. IOPS is reality, and throughput is something that only generally comes up in benchmarks.
Look into what ZFS can do with a spot of flash.
ZIL: http://blogs.sun.com/rdm/entry/zil_ssd_and_other_fun
L2ARC: http://blogs.sun.com/brendan/entry/test
I believe this is the "right way" the article is advocating. You can use it now.
ZIL: http://blogs.sun.com/rdm/entry/zil_ssd_and_other_fun
L2ARC: http://blogs.sun.com/brendan/entry/test
I believe this is the "right way" the article is advocating. You can use it now.
Am I missing something or is this pure filesystem cache? What happens instead if you configure an SSD as your swap device? Wouldn't the OS then be able to use the SSD more generally as a piece of the memory hierarchy?
This is only for ZFS. However, ZFS also does block devices, so in a typical deployment swap would be on a ZFS zvol.
I'm not sure how effective this would be, though. If you want to 'extend' the amount of RAM you have, it would be far better to mmap() a file rather than hope that everything works as you expect with swap.
I'm not sure how effective this would be, though. If you want to 'extend' the amount of RAM you have, it would be far better to mmap() a file rather than hope that everything works as you expect with swap.
This is a great idea, too bad it's chained to an obscure OS: http://leaf.dragonflybsd.org/cgi/web-man?command=swapcache
If the OS used the SSD as a swap device, it would still try to write the data back to the underlying drive within a reasonable period of time, which isn't necessary for SSD.
Unless I'm mistaken, you're still thinking of file writes. I'm talking about using your SSD as "slow RAM". Your statement is true, but it doesn't account for the use of SSD as something that could be used for very large ephemeral data structures.
But that wouldn't be too much of a problem. Actually it's a good idea, so that you can shovel in different data, in case those get hot.
[deleted]
Question about the article, and suggested use of hierarchical file storage: why would you want to make the user "mark" files? Why not just have the OS keep most-recently-used (perhaps weighted by size?) files on the fast disk, and migrate inactive files to the slow disk?
Or, just buy a hybrid disk and let the hardware do it.
Or, just buy a hybrid disk and let the hardware do it.
Or even most recently used blocks, instead of files.
"$8,000 for a 160GB model" according to the article. But looking at Newegg.com, it seems that you can buy 24GB of RAM for $750 so 8K could buy you 240GB with some cash left over.
And looking at supermicro's page, their 4U tower allows you to populate up to 192GB....
Naive analysis, since it doesn't take into account um..persistence, but still interesting to see how expensive these fusion io parts are...
And looking at supermicro's page, their 4U tower allows you to populate up to 192GB....
Naive analysis, since it doesn't take into account um..persistence, but still interesting to see how expensive these fusion io parts are...
The RAMCloud[1] project at Stanford tackles the problem of persistence. Each server has a RAM and a persistent store like a hard disk. The entire cluster's disks are used for persistence.
[1]: http://fiz.stanford.edu:8081/display/ramcloud/Home
[1]: http://fiz.stanford.edu:8081/display/ramcloud/Home
Where are you going to insert all this RAM? Did you calculate the number of motherboards you would need and how you'd connect all that?
Also, RAM resets as soon as you restart your computer.
Also, RAM resets as soon as you restart your computer.
You can buy a Dell R715 today with default configuration and 256GiB RAM for the low, low price of $26,231.
It's only naive in the Emperor's New Clothes sense.
High-end SSD[1] pricing has never made sense to me, but, then, I expect that the target market is "enterprise," where paying for the cost of sales, even/especially when it's a hefty multiple of the cost of the technology, is the norm.
ETA: The primary value of having something like this on the end of a PCIe or disk interface tether is that the size limit for a single machine becomes much higher than a single unit's capacity.
[1] Including DRAM-based ones historically, not just modern flash-based ones.
High-end SSD[1] pricing has never made sense to me, but, then, I expect that the target market is "enterprise," where paying for the cost of sales, even/especially when it's a hefty multiple of the cost of the technology, is the norm.
ETA: The primary value of having something like this on the end of a PCIe or disk interface tether is that the size limit for a single machine becomes much higher than a single unit's capacity.
[1] Including DRAM-based ones historically, not just modern flash-based ones.
Nobody mentions OCZ?
"And right now, they're also wallet-bustingly expensive, even for enterprise customers."
Check the revodrive - 480GB PCI-E drive, bootable, costs the same amount as a 512GB standard SSD with the SATA bottleneck.
"And right now, they're also wallet-bustingly expensive, even for enterprise customers."
Check the revodrive - 480GB PCI-E drive, bootable, costs the same amount as a 512GB standard SSD with the SATA bottleneck.
The article mentions it in the third paragraph:
If you want to go slower, smaller, and cheaper, you can pick up a consumer-grade, 80GB OCZ PCIe SSD card from Amazon for $300 and change, but you'll get only 540MB/s read and 450MB/s write.
If you want to go slower, smaller, and cheaper, you can pick up a consumer-grade, 80GB OCZ PCIe SSD card from Amazon for $300 and change, but you'll get only 540MB/s read and 450MB/s write.
Well, they have higher-end options too that go to 1.4GB/s, they're pricier but still way cheaper than fusionio -- roughly comparable to 1.25X the price per GB of a 2.5" drive for 5-10X the bandwidth.
Those are "fake" PCIe SSDs (really just a bunch of SATA SSDs attached to a RAID controller), not "native" which are theoretically supposed to be cheaper.
Yeah, but they work and they give you the throughput. Engineering smarts, why build an expensive SSD->PCIE component when you can buy cheapo 4xSSD->RAID->PCIE existing parts and slap them on the card?
only the Revodrive x2 is bootable
http://semiaccurate.com/2010/10/28/ocz-announces-revodrive-x...
[deleted]
> Intel, Dell, IBM, EMC, and a host of other component makers and
> OEMs have announced a partnership aimed at developing a standard
> interface for PCIe-hosted solid-state disks
I'm curious, if they don't use PCIe, what interface would they use?
"in that they put the OS partition and swapfile on a fast SSD"
So at $8,000 for 160GB, we now use ultra expensive SSD as an alternative for more cheap faster RAM? You do remember why swap was invented - because memory was scarce and disk was cheap.
So at $8,000 for 160GB, we now use ultra expensive SSD as an alternative for more cheap faster RAM? You do remember why swap was invented - because memory was scarce and disk was cheap.
Violin Memory does just that (no relation) http://www.violin-memory.com/products/dram/
I'm not finding it on their page, but they had one product that was 1TB of ram, backed by a 1 TB disk with a backup-battery. You get super fast storage, and if the power went out, the TB of ram would get saved to disk.
I'm not finding it on their page, but they had one product that was 1TB of ram, backed by a 1 TB disk with a backup-battery. You get super fast storage, and if the power went out, the TB of ram would get saved to disk.
Yup, I second violin.
They have it about right when you're really starving for IOPS. It naturally comes at a price. But last time I checked the violin's were a much more natural next step after maxing out local SSDs and RAM than the FusionIO devices (which seem more like a stopgap-solution rather than a scaling path).
They have it about right when you're really starving for IOPS. It naturally comes at a price. But last time I checked the violin's were a much more natural next step after maxing out local SSDs and RAM than the FusionIO devices (which seem more like a stopgap-solution rather than a scaling path).
"I second violin"
:)
:)
Yes thats a good caching scheme for a harddrive.
But my point remains. I have say 1Gb of ram, I need more memory, so I turn on swap, swap is slow so I go out and buy a super-expensive SSD hard drive instead of just buying more ram.
But my point remains. I have say 1Gb of ram, I need more memory, so I turn on swap, swap is slow so I go out and buy a super-expensive SSD hard drive instead of just buying more ram.
Are they also SuperHot ?
SSD's should result in huge performance boosts, especially with nosql systems like MongoDB & CouchDB. Can't wait until the prices start to drop!
I would have thought the biggest performance boost would have come for databases based on B-tree-like structures on large datasets.
You have to read to read and read to write. Every depth of the tree that doesn't fit into main memory costs you a random read, whether to read or write.
You have to read to read and read to write. Every depth of the tree that doesn't fit into main memory costs you a random read, whether to read or write.
Write amplification (http://en.wikipedia.org/wiki/Write_amplification) means that naive random writes like what you see from b-trees are going to degrade performance on SSDs too (although not as pathologically as doing rotational seeks). In other words it still pays to be smart about i/o patterns.
>SSD's should result in huge performance boosts, especially with nosql systems like MongoDB & CouchDB.
This is entirely backwards. NoSQL solutions tend to trade space for reduced I/O, whereas a relational database trades I/O for reduced space.
This is entirely backwards. NoSQL solutions tend to trade space for reduced I/O, whereas a relational database trades I/O for reduced space.
Not really. Both systems wind up IO-bound very quickly if you're out of memory. NoSQL systems might get to a higher number of requests/second before flatlining, but they're still fundamentally disk bound unless your dataset fits in memory.
I was specifically replying to the "especially" bit. The net benefit of an SSD is far less pronounced with many NoSQL solutions (in particular document stores) than with relational databases. That's because the former was built and adopted largely to make lemonade out of the I/O problem (particularly on terrible I/O platforms like AWS).
IMO: sure, that would be nice, but he's overstating his case. SSD's are even more useful as the main hard drive than just a cache. 80-160GB (the current sweet spot for cheap SSD's) is big enough for 80% of all users, in 12 months, we'll have hit 95%. The only operating system that moves fast enough to add support for something like this in that sort of timeframe is Linux, which is only used by 1% of desktop users anyways. (And Linux works well in a 10-20GB partition, let alone 160GB)...