Micron releases half-terabyte laptop SSDs(macworld.com)
macworld.com
Micron releases half-terabyte laptop SSDs
http://www.macworld.com/article/156849/2011/01/micron.html
6 comments
I recently replaced the SAS drives in all of my database servers with SSDs. Watching IO wait on my usage graphs drop while db latency fell to near-0ms was such an incredibly gratifying feeling. Worth every penny.
If you've got heavy random IO on your dataset (90% active, OLTP here) and/or deal with any sort of significant contention or deadlocking across your disks, I would strongly encourage upgrading to SSDs. Of course, if you can fit your dataset into RAM, go that route. But if you're well past that point, might be time to consider SSDs.[1]
[1] http://www.mysqlperformanceblog.com/2010/04/08/fast-ssd-or-m...
If you've got heavy random IO on your dataset (90% active, OLTP here) and/or deal with any sort of significant contention or deadlocking across your disks, I would strongly encourage upgrading to SSDs. Of course, if you can fit your dataset into RAM, go that route. But if you're well past that point, might be time to consider SSDs.[1]
[1] http://www.mysqlperformanceblog.com/2010/04/08/fast-ssd-or-m...
I wonder if Amazon's EBS will support SSD anytime soon. That would rock.
It's quite impractical for them to "support" SSD. The way (I assume) their infrastructure works would basically mean that the speedup you get from SSD would be nullified by the rest of the IO needs imposed by their stack. That is, if they were to simply move one service (in this case, EBS) to SSD.
The only way I see this happening is if they start adding servers with SSD, where all services running on those servers support SSD too. This would basically mean a separate cluster, fully based on SSD. I don't see this happening soon.
The only way I see this happening is if they start adding servers with SSD, where all services running on those servers support SSD too. This would basically mean a separate cluster, fully based on SSD. I don't see this happening soon.
They don't have to move to support EBS with SSD and mix and match. They could have RDS instances with SSD only option and EBS based on SSD. They can charge significant amount for those options, some might even pay for it.
Isn't the rule "If you touch it more than once a day, move it to flash, if you touch it more than once an hour, move it to RAM?"
That is, for data which is touched daily, it's already less expensive to use flash than magnetic drives. The problem with Hard Drives is that in order to get the IOPs, we always end up buying a _ton_ of drives, plus the chassis to support those drives, plus the licenses to support the amount of storage represented by those drives, etc, etc, ...
That is, for data which is touched daily, it's already less expensive to use flash than magnetic drives. The problem with Hard Drives is that in order to get the IOPs, we always end up buying a _ton_ of drives, plus the chassis to support those drives, plus the licenses to support the amount of storage represented by those drives, etc, etc, ...
I haven't done the cost analysis lately, but what this does is bring more IOPS in at a lower price point. The cost of RAM is not static, the more you have the more expensive it gets because you need better motherboards and specialized chassis to handle it and really manage all those buses. SSDs bring in an intermediate point between magnetic disks and RAM so that you can get some more IOPS in at that lower price point.
Of course, if you need all you can get you should always go for just RAM, but you can get a significant improvement with a modest investment through SSDs.
The best example would be the large data set (say 100GB with a random access pattern or 100GB of working set) with enough requests that it starting to strain the RAID system you have. At this point your medium is saturated so latency is going up and up. Getting 128 GB of RAM is expensive, but swapping those drives out for a few 100GB SSDs is not hard and may alleviate the DB bottle-neck until something else becomes the bottle-neck and you need to change that anyway. Switching to RAM wouldn't have bought you anything more than the SSDs because in both cases you are getting acceptable performance up to the next bottleneck.
I'd like to think that SSDs will get us to the point that we don't have to worry about disk latency and can just toss data on there without having the database always be the bottleneck.
Of course, if you need all you can get you should always go for just RAM, but you can get a significant improvement with a modest investment through SSDs.
The best example would be the large data set (say 100GB with a random access pattern or 100GB of working set) with enough requests that it starting to strain the RAID system you have. At this point your medium is saturated so latency is going up and up. Getting 128 GB of RAM is expensive, but swapping those drives out for a few 100GB SSDs is not hard and may alleviate the DB bottle-neck until something else becomes the bottle-neck and you need to change that anyway. Switching to RAM wouldn't have bought you anything more than the SSDs because in both cases you are getting acceptable performance up to the next bottleneck.
I'd like to think that SSDs will get us to the point that we don't have to worry about disk latency and can just toss data on there without having the database always be the bottleneck.
While SSDs are wonderful for random reads, writes are still very expensive due to their large erase blocks. In a small write (typical OLTP workload), the entire block has to be rewritten --typically 128kB-- even if the modified data is much smaller. That's why it is very important to make the application aware of this fact, or use a log-structured filesystem on top of it.
I believe that for most web applications the ratio is 80% reads, 20% writes, that's why no one has noticed this behavior.
Another even more concerning issue is the wear-out, SSD cells can't take more than ~10000 rewrites. While there is firmware taking care of invalidating those blocks, eventually we can expect data loss if not backed up properly.
I think SSDs are great, as long as we understand their limits... For my laptop I have one and I love it, but I would be seriously doubtful about the safety of my information in some database using purely SSDs.
I believe that for most web applications the ratio is 80% reads, 20% writes, that's why no one has noticed this behavior.
Another even more concerning issue is the wear-out, SSD cells can't take more than ~10000 rewrites. While there is firmware taking care of invalidating those blocks, eventually we can expect data loss if not backed up properly.
I think SSDs are great, as long as we understand their limits... For my laptop I have one and I love it, but I would be seriously doubtful about the safety of my information in some database using purely SSDs.
For servers, you'd typically choose SLC Flash rather than the cheaper MLC. The memory cells survive about an order of magnitude more flash cycles and are also slightly faster. Also, I hope you're not assuming that your data is safe on the only component with critical moving parts in a modern computer...
"Half-terabyte": because "512 gigabyte" just doesn't sound as impressive.
Really, though, what I'm interested in is getting enough SSD space at a reasonable price. That might not make quite so eye-catching a headline, though.
Really, though, what I'm interested in is getting enough SSD space at a reasonable price. That might not make quite so eye-catching a headline, though.
Define enough? Also what's your $/GB ratio threshold? You can already get ssd's for $1-2/GB. That's the same price as platter based storage was around 8 years ago. At this point I'd say that SSD's are reasonable enough for a boot disk or mobile use at least.
I picked up an 80GB disk for my system a few years ago, when the X25-M2 model came out from Intel with a price drop. It was great. Firefox launches in 2 seconds, GRUB to login in < 10s, login to desktop in < 5 seconds.
What really hit me hard was gaming. I like to play a few video games from time to time, but they are getting HUGE! For example, World of Warcraft take up about 13GB, and to upgrade to the 4.0 patch it required an additional 20GB (it didn't say this, but that's how much space I had to free before it was able to complete). That's about 35GB for one game, and that's half the space on my SSD. I installed StarCraft II recently and that required 6GB for the download and 14GB for installation.
Of course, when I moved the games to an older disk I suddenly had over 50GB free.
It's my observation that disk will tend to fill up. First it was with programs, then it was with audio, now it is with video and video games.
As soon as we get more space, we will increase the resolution/fidelity until the average person can't tell the difference from a live event.
What really hit me hard was gaming. I like to play a few video games from time to time, but they are getting HUGE! For example, World of Warcraft take up about 13GB, and to upgrade to the 4.0 patch it required an additional 20GB (it didn't say this, but that's how much space I had to free before it was able to complete). That's about 35GB for one game, and that's half the space on my SSD. I installed StarCraft II recently and that required 6GB for the download and 14GB for installation.
Of course, when I moved the games to an older disk I suddenly had over 50GB free.
It's my observation that disk will tend to fill up. First it was with programs, then it was with audio, now it is with video and video games.
As soon as we get more space, we will increase the resolution/fidelity until the average person can't tell the difference from a live event.
Good point. This is approaching the "enough space to be the only drive" threshold for me, so this is pretty exciting.
Actually, according to HD manufacturers, 0.5 TiB is roughly equal to 465.66 GB. That's a difference of almost 50GB.
According to everyone _except_ memory manufacturers, 1/2 Terabyte = 500 Gigabytes = 5*10^11 Bytes.
See: http://www.tarsnap.com/GB-why.html
I can't find a single other example, other than Memory where "Giga" isn't 10^9.
The question is - SSDs - Memory or Disk? :-)
See: http://www.bit-tech.net/hardware/storage/2010/06/25/sandforc...
In addition to the GB vs GiB, the use of NAND disk over-provisioning and partition formatting further complicates issues - the punchline:
"The 100GB SandForce-based drives use a massive 28 per cent of over provisioning, leaving just 93.16GB of formatted capacity despite their 128GiB of NAND storage"
See: http://www.tarsnap.com/GB-why.html
I can't find a single other example, other than Memory where "Giga" isn't 10^9.
The question is - SSDs - Memory or Disk? :-)
See: http://www.bit-tech.net/hardware/storage/2010/06/25/sandforc...
In addition to the GB vs GiB, the use of NAND disk over-provisioning and partition formatting further complicates issues - the punchline:
"The 100GB SandForce-based drives use a massive 28 per cent of over provisioning, leaving just 93.16GB of formatted capacity despite their 128GiB of NAND storage"
[deleted]
I could be wrong but I think SSDs tend to come in actual powers of two, or genuine 500GB
SSDs have their own ways to shrink the physical capacity.
For example the new SandForce chipsets needed 20%(!) of the flash-capacity for their scratch space when they were initially released. I think they have that down to around 6% now.
However, regardless of the figures, the harddrive vendors have a user-base that was trained for decades that harddrives are supposed to be smaller than advertised. I doubt they will stop taking advantage of that.
For example the new SandForce chipsets needed 20%(!) of the flash-capacity for their scratch space when they were initially released. I think they have that down to around 6% now.
However, regardless of the figures, the harddrive vendors have a user-base that was trained for decades that harddrives are supposed to be smaller than advertised. I doubt they will stop taking advantage of that.
It's not just scratch. It's also spare capacity and stuff to deal with level wearing. They also advertise the actual usable space as opposed to the 'max' space. A SSD might actually have 256GB of space, but it'll be advertised as 240GB. They're actually fairly honest.
Remember, most of the major SSD manufacturers -aren't- harddrive manufacturers. They're chip and memory manufacturers (which makes sense).
Remember, most of the major SSD manufacturers -aren't- harddrive manufacturers. They're chip and memory manufacturers (which makes sense).
"Actual powers of two" would imply 512 GB.
It's very cool that ssd's are getting the sizes to be able to replace my hard drive rather than just be used in laptops or be used as a boot disk. Hopefully the controller will be as fast as they claim and be competitive with intel and OCZ. The only problem, is that as the manufacturicing process has shrunk (from 50nm, to 30nm, to now 25nm I think), the number of writes before the NAND would no longer hold a charge has significantly decreased from 10000 to 5000 and downward. While these are still large enough for heavy use to last a few years, hopefully these new drives will still be able to last a few years with sustained use.
Or at least, this is my current understanding of SSD tech.
I believe the high end Crucial drives use Sandforce controllers, which are currently the top of the heap, and OCZ uses them in their best drives. Current Sandforce controllers beat out the Intel G2, but I don't know how it's supposed to stack up against the G3.
Crucial SSDs use a Marvell/Micron controller which does very well in many benchmarks. http://www.anandtech.com/show/3812/the-ssd-diaries-crucials-...
Ahh thanks, that was the article I was trying to find last night but didn't manage to.
[deleted]
Almost certainly a response to the 600 gigabyte Intel SSDs that should be on sale any day now.
http://www.anandtech.com/show/3965/intels-3rd-generation-x25...
http://www.anandtech.com/show/3965/intels-3rd-generation-x25...
It was supposed to be announced for 2010 Q4. Some think it might get delayed until 2011 Q2. Best to wait to see if it gets announced at CES in a few days.
I love watching a new technology go exponential. By this time next year we'll be talking about 1TB laptop SSDs, and from there it won't be too long until their capacities outpace platter tech.
Anyone got any recommendations for SSDs for a MBP? Should I wait a few months for one of the new ones?
I've got a 80GB SSD in my MBP, but it's feeling a little small.
The whole TRIM / garbage collection stuff got me feeling confused.
I've got a 80GB SSD in my MBP, but it's feeling a little small.
The whole TRIM / garbage collection stuff got me feeling confused.
C300 by Crucial. I upgraded my 13" MBP with it a few months back (6? 8?) and it's unbelievable. They say OS X doesn't need TRIM, but I don't really believe that.
Another option if you don't use your optical drive is to install a normal 2.5" HD instead over there for not-oft-used data.
Another option if you don't use your optical drive is to install a normal 2.5" HD instead over there for not-oft-used data.
Be careful - the shock protection for disks works only in the normal HDD bay - put your SSD in optibay, not your HDD.
I've read that putting your OS disk in the optibay can cause major problems with resuming from sleep - has this been fixed, or do you just set it to "shut down when lid is closed"?
Definitely concur on this. A C300 in the standard drive bay and a seagate momentus xt in the optibay is a wonderful combination (or a second ssd if you are really trying to pimp your ride...)
I recently upgraded my MBP 5,1 from a WDC Black to an OCZ Vertex 2E and I'm really impressed. My XBench stats aren't as high as other people with the same drive, but I'm more than happy w/ it.
This is good news for databases. Flash drives have much better random access performance than magnetic drives. With the price of these flash drives dropping, it will soon be cost-effective to replace an entire database with flash for the IOPS increase. Right now people are using flash for extra cache, but soon we'll be able to fit the whole database in flash for a reasonable $/IOPS.
It will extend the life of single-instance databases significantly, and mean everyone can wait that much longer before distributing the database.