The SSD Relapse: Understanding and Choosing the Best SSD
by Anand Lal Shimpi on August 30, 2009 12:00 AM EST- Posted in
- Storage
Live Long and Prosper: The Logical Page
Computers are all about abstraction. In the early days of computing you had to write assembly code to get your hardware to do anything. Programming languages like C and C++ created a layer of abstraction between the programmer and the hardware, simplifying the development process. The key word there is simplification. You can be more efficient writing directly for the hardware, but it’s far simpler (and much more manageable) to write high level code and let a compiler optimize it.
The same principles apply within SSDs.
The smallest writable location in NAND flash is a page; that doesn’t mean that it’s the largest size a controller can choose to write. Today I’d like to introduce the concept of a logical page, an abstraction of a physical page in NAND flash.
Confused? Let’s start with a (hopefully, I'm no artist) helpful diagram:
On one side of the fence we have how the software views storage: as a long list of logical block addresses. It’s a bit more complicated than that since a traditional hard drive is faster at certain LBAs than others but to keep things simple we’ll ignore that.
On the other side we have how NAND flash stores data, in groups of cells called pages. These days a 4KB page size is common.
In reality there’s no fence that separates the two, rather a lot of logic, several busses and eventually the SSD controller. The latter determines how the LBAs map to the NAND flash pages.
The most straightforward way for the controller to write to flash is by writing in pages. In that case the logical page size would equal the physical page size.
Unfortunately, there’s a huge downside to this approach: tracking overhead. If your logical page size is 4KB then an 80GB drive will have no less than twenty million logical pages to keep track of (20,971,520 to be exact). You need a fast controller to sort through and deal with that many pages, a lot of storage to keep tables in and larger caches/buffers.
The benefit of this approach however is very high 4KB write performance. If the majority of your writes are 4KB in size, this approach will yield the best performance.
If you don’t have the expertise, time or support structure to make a big honkin controller that can handle page level mapping, you go to a larger logical page size. One such example would involve making your logical page equal to an erase block (128 x 4KB pages). This significantly reduces the number of pages you need to track and optimize around; instead of 20.9 million entries, you now have approximately 163 thousand. All of your controller’s internal structures shrink in size and you don’t need as powerful of a microprocessor inside the controller.
The benefit of this approach is very high large file sequential write performance. If you’re streaming large chunks of data, having big logical pages will be optimal. You’ll find that most flash controllers that come from the digital camera space are optimized for this sort of access pattern where you’re writing 2MB - 12MB images all the time.
Unfortunately, the sequential write performance comes at the expense of poor small file write speed. Remember that writing to MLC NAND flash already takes 3x as long as reading, but writing small files when your controller needs large ones worsens the penalty. If you want to write an 8KB file, the controller will need to write 512KB (in this case) of data since that’s the smallest size it knows to write. Write amplification goes up considerably.
Remember the first OCZ Vertex drive based on the Indilinx Barefoot controller? Its logical page size was equal to a 512KB block. OCZ asked for a firmware that enabled page level mapping and Indilinx responded. The result was much improved 4KB write performance:
| Iometer 4KB Random Writes, IOqueue=1, 8GB sector space | Logical Block Size = 128 pages | Logical Block Size = 1 Page |
| Pre-Release OCZ Vertex | 0.08 MB/s | 8.2 MB/s |
Facebook
Twitter
RSS
295 Comments
View All Comments
Anand Lal Shimpi - Monday, August 31, 2009 - link
wow I misspelled my own name :) Time to sleep for real this time :)Take care,
Anand
IntelUser2000 - Monday, August 31, 2009 - link
Looking at pure max TDP and idle power numbers and concluding the power consumption based on those figures are wrong.Look here: http://www.anandtech.com/cpuchipsets...px?i=3403&a...">http://www.anandtech.com/cpuchipsets...px?i=3403&a...
Modern drives quickly reach idle even between times where the user don't even know and at "load". Faster drives will reach lower average power because it'll work faster to get to idle. This is why initial battery life tests showed X25-M with much higher active/idle power figures got better battery life than Samsungs with less active/idle power.
Max power is important, but unless you are running that app 24/7 its not real at all, especially the max power benchmarks are designed to reach close to TDP as possible.
Anand Lal Shimpi - Monday, August 31, 2009 - link
I agree, it's more than just max power consumption. I tried to point that out with the last paragraph on the page:"As I alluded to before, the much higher performance of these drives than a traditional hard drive means that they spend much more time at an idle power state. The Seagate Momentus 5400.6 has roughly the same power characteristics of these two drives, but they outperform the Seagate by a factor of at least 16x. In other words, a good SSD delivers an order of magnitude better performance per watt than even a very efficient hard drive."
I didn't have time to run through some notebook tests to look at impact on battery life but it's something I plan to do in the future.
Take care,
Anand
IntelUser2000 - Monday, August 31, 2009 - link
Thanks, people pay too much attention to just the max TDP and idle power alone. Properly done, no real apps should ever reach max TDP for 100% of the duration its running at.cristis - Monday, August 31, 2009 - link
page 6: "So we’re at approximately 36 days before I exhaust one out of my ~10,000 write cycles. Multiply that out and it would take 36,000 days" --- wait, isn't that 360,000 days = 986 years?Anand Lal Shimpi - Monday, August 31, 2009 - link
woops, you're right :) Either way your flash will give out in about 10 years and perfectly wear leveled drives with no write amplification aren't possible regardless.Take care,
Anand
cdillon - Monday, August 31, 2009 - link
I gather that you're saying it'll give out after 10 years because a flash cell will lose its stored charge after about 10 years, not because the write-life will be surpassed after 10 years, which doesn't seem to be the case. The 10-year charge life doesn't mean they become useless after 10 years, just that you need to refresh the data before the charge is lost. This makes flash less useful for data archival purposes, but for regular use, who doesn't re-format their system (and thus re-write 100% of the data) at least once every 10 years? :-)Zheos - Monday, August 31, 2009 - link
"This makes flash less useful for data archival purposes, but for regular use, who doesn't re-format their system (and thus re-write 100% of the data) at least once every 10 years? :-)"I would like an input on that too, cuz thats a bit confusing.
GourdFreeMan - Tuesday, September 1, 2009 - link
Thermal energy (i.e. heat) allows the electrons trapped in the floating gate to overcome the potential well and escape, causing zeros (represented by a larger concentration of electrons in the floating gate) to eventually become ones (represented by a smaller concentration of electrons in the floating gate). Most SLC flash is rated at about 10 years of data retention at either 20C (68F) or 25C (77F). What Anand doesn't mention is that as a rule of thumb for every 9 degrees C (~16F) that the temperature is raised above that point, data retention lifespan is halved. (This rule of thumb only holds for human habitable temperatures... the exact relation is governed by the Arrhenius equation.)Wear leveling and error correction codes can be employed to mitigate this problem, which only gets worse as you try to store more bits per cell or use a smaller lithography process without changing materials or design.
Zheos - Tuesday, September 1, 2009 - link
Thank you GourdFreeMan for the additional input,But, if we format like every year or so , doesnt the countdown on data retention restart from 0 ? or after ~10 year (seems too be less if like you said temperature affect it) the SSD will not only fail at times but become unusable ? Or if we come to that point a format/reinstall would resolve the problem ?
I dont care about losing data stored after 10 years, what i do care is if the drive become ASSURELY unsusable after 10 year maximum. For drives that comes at a premium price, i don't like this if its the case.