Solid-state storage devices and the block layer [LWN.net]

Solid-state storage devices and the block layer

Posted Oct 9, 2010 14:10 UTC (Sat) by joern (subscriber, #22392)
In reply to: Solid-state storage devices and the block layer by jzbiciak
Parent article: Solid-state storage devices and the block layer

> Flash does require you to think about how you pool your free sectors, though, and how you schedule writing versus erasing.

Intriguing. Can you elaborate a bit? What difference does it make vs. the naïve approach of erasing before writing?

(Log in to post comments)

Solid-state storage devices and the block layer

Posted Oct 9, 2010 14:55 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]

the issue is that you have to erase large chunks (on the order of 128K bytes), if you are then writing in small chunks (say the 512 byte sectors that are the default, or even the 4K byte filesystem blocks) you can't just erase just before writing.

you also have the problem that erasing takes a significant amount of time and power to accomplish, so you don't want to wait until you need to erase to do so and you don't want to erase when you don't need to and are on battery

Solid-state storage devices and the block layer

Posted Oct 9, 2010 15:03 UTC (Sat) by jzbiciak (✭ supporter ✭, #5246) [Link]

Note: I'm not an expert. Please do not mistake me for one. :-) Here are my observations, though, along with things I've read elsewhere.

Flash requires wear leveling in order to maximize its life. For the greatest effect, you want to wear level across the entire device, which means picking up and moving otherwise quiescent data so that each sector sees approximately the same number of erasures. That's one aspect.

Another aspect is that erase blocks are generally much larger than write sectors. So, when you do erase, you end up erasing quite a lot. Furthermore erasure is about an order of magnitude slower than writing, and writing is about an order of magnitude slower than reading. For a random flash device whose data sheet I just pulled up, a random read takes 25us, page program takes 300us, and block erase takes 2ms. Pages are 2K bytes, whereas erase blocks are 128K bytes.

(Warning: This is where I get speculative!) And finally, if you have multiple flash devices (or multiple independent zones on the same flash device), you can take advantage of that fact and the fact that "seeks are free" by redirecting writes to idle flash units if others are busy. That's probably the most interesting area to explore algorithmically, IMO. Given that an erase operation can take a device out of commission for 2ms, picking which device to start an erase operation on and when to do it can have a pretty big impact on performance. If you can do background erase on idle devices, for example, then you can hide the cost.