What we learned about SSDs in 2015
zdnet.com
What we learned about SSDs in 2015
1–10 of 111 posts
Re: What we learned about SSDs in 2015
#2Does NVMe solve the garbage collection problem?
Re: What we learned about SSDs in 2015
#3Not so sure. There are plenty of benefits to SSD too. I suspect system designers will just add more RAM to act as cache to offset some of these performance issues. Not to mention further improve temperature control.
Re: What we learned about SSDs in 2015
#4Not so sure. There are plenty of benefits to SSD too. I suspect system designers will just add more RAM to act as cache to offset some of these performance issues. Not to mention further improve temperature control.
More RAM means more reserve power needed to flush it to permanent storage when the main power is cut.
What's more likely to happen is exposing the low level storage and software to kernel drivers.
Re: What we learned about SSDs in 2015
#5Does NVMe solve the garbage collection problem?
NVMe is just the communications protocol between the host and device. Garbage collection is due to hiding the non ideal properties of the NAND from the host. Primary among them is endurance limits and the size difference between write and erase units. You could for example move the handling of some of these GC details to the OS filesystem level but then that becomes more complicated and has to deal with the differences with each NAND technology generation. You couldn't just copy a file system image from one drive to another for example.
Re: What we learned about SSDs in 2015
#6At one of my previous employers, they built a massive "cloud" storage system. The underlying file system was ZFS, which was configured to put its write logs onto an SSD. With the write load on the system, the servers burnt through an SSD in about a year, i.e. most SSDs started failing after about a year. The hardware vendors knew how far you could push SSDs, and thus refused to give any warranty. All the major SSD vendors told us SSDs are strictly considered wearing parts. That was back in 2012 or 2013.
Re: What we learned about SSDs in 2015
#7At one of my previous employers, they built a massive "cloud" storage system. The underlying file system was ZFS, which was configured to put its write logs onto an SSD. With the write load on the system, the servers burnt through an SSD in about a year, i.e. most SSDs started failing after about a year. The hardware vendors knew how far you could push SSDs, and thus refused to give any warranty. All the major SSD ve…
If your SSDs were wearing out after a year, and were warrantied for a year, I'm guessing you weren't using "enterprise" SSDs?
Re: What we learned about SSDs in 2015
#8Kind of stupid to end with "Since CPUs aren't getting faster, making storage faster is a big help."
CPUs and storage exist for completely disjoint purposes, and the fastest CPU in the world can't make up for a slow disk (or vice versa). Anyway, CPUs are still "faster" than SSDs, whatever that means, if you wish to somehow compare apples to oranges. That's why even with NVMe if you are dealing with compressible data enabling block compression in your FS can speed up your IO workflow.
Re: What we learned about SSDs in 2015
#9May be SSD should add something like "raw mode", when controller just reports everything he knows about disk, and operating system takes in control the disk, so firmware won't cause unexpected pauses. After all, operating system knows more, what files are not likely to be touched, what files are changing often, etc.
Re: What we learned about SSDs in 2015
#10Kind of stupid to end with "Since CPUs aren't getting faster, making storage faster is a big help." CPUs and storage exist for completely disjoint purposes, and the fastest CPU in the world can't make up for a slow disk (or vice versa). Anyway, CPUs are still "faster" than SSDs, whatever that means, if you wish to somehow compare apples to oranges. That's why even with NVMe if you are dealing with compressible data e…
Your process spends some amount of time waiting on various resources; some of those may be CPU-bound, some may be disk-bound. Speeding either of those up will make your process faster. In fact, you can even trade one for the other if you use compression.