3 ms·

> However, there remain two serious problems limiting wider deployment of SSDs: limited lifespan and relatively poor random write performance. This i

> However, there remain two serious problems limiting wider deployment of SSDs: limited lifespan and relatively poor random write performance. This is a 5 year old paper which is an eternity in SSD engineering. Anyone know if ssd firmwares today handle this better? Last gen consumer SSD was hitting nearly 100K IOPS on random writes which is 3-4x better than a spinning disk. On random reads you're looking at least 50-100x difference. As far as limited lifespan goes, a fairly popular study from 2014 showed that even a consumer Samsung SSD could hit 2 petabytes without fault. A 2016 study by Google showed that the write endurance of its drive isn't correlated with failure, but its age. So these things are aging out moreso than exhausting its writable NAND. That's on top of a lower replacement rate than spinning disks. http://www.techradar.com/news/computing-components/storage/think-your-ssd-will-last-forever-google-has-some-answers-on-that-1316031 http://www.techradar.com/news/computing-components/storage/t... Not sure what current gen is doing, but I imagine its even better. It seems like there's been a lot of work towards write leveling and extending endurance lately and in our own data center we're seeing a lower fail rate of SSD's than we did with spinning disks. Not sure of all the black magic involved here, but from both a desktop and server perspective we never experienced the SSD doomsday scenarios often listed out in the early 2010's when SSDs began to dominate. Curious to know if modern SSDs have worked around the worst issues with flash-based media. It seems they have.

wtallis 9y ago
The biggest thing missing from the paper seems to be SLC caching, which is now nearly universal on client SSDs but usually not used on enterprise SSDs. Modern SSDs also use much more robust error correction schemes than they did 5 years ago; almost everything has LDPC soft-decode or similar as a fallback, which gives an effective increase in the write endurance of the drive. There are also trends underway to dismantle some of the abstractions between the file system and the flash. Even when a SSD is presenting an interface of 512B or 4kB logical blocks for compatibility reasons, it can inform the host of the optimal block size to use for I/O. The host can also tag I/O commands with a stream ID, allowing the SSD to store related data together and separate from unrelated streams. Used properly, this approximates generational garbage collection and improves both performance and write amplification. There's also a recently standardized feature for partitioning a SSD in a way that makes hard guarantees about the sharing (or lack thereof) of memory channels and flash chips. This is intended primarily for multi-tenant use cases, to ensure that one process/VM's I/O won't inflict garbage collection pauses upon another process/VM. In a similar vein, there are now mechanisms to request that the SSD defer all background processing for a while in order to service a burst of I/O with minimal and predictable latency, and controls for whether a SSD is permitted to do non-critical background processing during idle time (you may not want that happening while running on battery). Beyond that, there's some work on open-channel SSDs that move large portions of the flash translation layer to the host system, allowing all the above controls and more to be managed by the host. With application-layer tuning this can be extremely powerful.
baruch 9y ago
I've worked on ssd based systems and while we over-engineered our system due to such fears we never saw any device getting anywhere close to its limits and only once did I see an SSD have a media problem (i.e. failure to read data previously written, after a rewrite of the data from raid no more issues came from that ssd). This was on enterprise SSDs but I generally believe that the fear from SSD media is somewhat overblown. You do need to care about the wear you will put on the SSD and engineer things so that you are within bounds but the SSD makers and the firmware essentially assume and spec for these random writes. In fact, I truly doubt that unless you can as an app know in advance what data is going to have the same lifetime and is better written together and what data needs to be placed in different places there is very little that you can do to make things far better. When you know the lifetimes you can use new features like stream support that is going into newer SSDs in order to help both sides work better. You will get longer endurance and also better performance (less random erase cycles slowing your reads and writes down).
- baruch 9y ago
  An issue with their work for current SSDs is that the write groups they use are about 16MB to 32MB, current SSDs, need far larger write sizes in order to get the optimization they used to get (essentially they tried to fill an entire erase group at once to get control of the locality). This will no longer work at the same level it worked before. Their estimate of improving endurance is based on using a disk simulator with FTL and not by checking the actual wear level change before and after their test which to me would be fairly suspect. They are not testing against a real FTL and full world behavior of the SSD and are rather "inventing" a test which is very limited and doesn't say much. Admittedly, testing the way I suggest would require a far longer test and take a lot longer but this is the only thing that really tells you if you are making things work in real life. SSDs are also affected by the workload and especially by any down times that you give it. If you let the SSD sit with no queued commands it will clear buffers and do maintenance work that will improve its behavior which will also affect the result so to get a real "real-world" behavior you need to factor that as well which will increase your test time.

wtallis 9y ago

The biggest thing missing from the paper seems to be SLC caching, which is now nearly universal on client SSDs but usually not used on enterprise SSDs. Modern SSDs also use much more robust error correction schemes than they did 5 years ago; almost everything has LDPC soft-decode or similar as a fallback, which gives an effective increase in the write endurance of the drive. There are also trends underway to dismantle some of the abstractions between the file system and the flash. Even when a SSD is presenting an interface of 512B or 4kB logical blocks for compatibility reasons, it can inform the host of the optimal block size to use for I/O. The host can also tag I/O commands with a stream ID, allowing the SSD to store related data together and separate from unrelated streams. Used properly, this approximates generational garbage collection and improves both performance and write amplification. There's also a recently standardized feature for partitioning a SSD in a way that makes hard guarantees about the sharing (or lack thereof) of memory channels and flash chips. This is intended primarily for multi-tenant use cases, to ensure that one process/VM's I/O won't inflict garbage collection pauses upon another process/VM. In a similar vein, there are now mechanisms to request that the SSD defer all background processing for a while in order to service a burst of I/O with minimal and predictable latency, and controls for whether a SSD is permitted to do non-critical background processing during idle time (you may not want that happening while running on battery). Beyond that, there's some work on open-channel SSDs that move large portions of the flash translation layer to the host system, allowing all the above controls and more to be managed by the host. With application-layer tuning this can be extremely powerful.

baruch 9y ago

I've worked on ssd based systems and while we over-engineered our system due to such fears we never saw any device getting anywhere close to its limits and only once did I see an SSD have a media problem (i.e. failure to read data previously written, after a rewrite of the data from raid no more issues came from that ssd). This was on enterprise SSDs but I generally believe that the fear from SSD media is somewhat overblown. You do need to care about the wear you will put on the SSD and engineer things so that you are within bounds but the SSD makers and the firmware essentially assume and spec for these random writes. In fact, I truly doubt that unless you can as an app know in advance what data is going to have the same lifetime and is better written together and what data needs to be placed in different places there is very little that you can do to make things far better. When you know the lifetimes you can use new features like stream support that is going into newer SSDs in order to help both sides work better. You will get longer endurance and also better performance (less random erase cycles slowing your reads and writes down).

baruch 9y ago
An issue with their work for current SSDs is that the write groups they use are about 16MB to 32MB, current SSDs, need far larger write sizes in order to get the optimization they used to get (essentially they tried to fill an entire erase group at once to get control of the locality). This will no longer work at the same level it worked before. Their estimate of improving endurance is based on using a disk simulator with FTL and not by checking the actual wear level change before and after their test which to me would be fairly suspect. They are not testing against a real FTL and full world behavior of the SSD and are rather "inventing" a test which is very limited and doesn't say much. Admittedly, testing the way I suggest would require a far longer test and take a lot longer but this is the only thing that really tells you if you are making things work in real life. SSDs are also affected by the workload and especially by any down times that you give it. If you let the SSD sit with no queued commands it will clear buffers and do maintenance work that will improve its behavior which will also affect the result so to get a real "real-world" behavior you need to factor that as well which will increase your test time.