"2015 was the beginning of the end for SSDs in the data center." is quit a bold statement especial when not discussing any alternative. I do not see us going back to magnetic disk, and most new storage technology are some kind of ssd...
What we learned about SSDs in 2015
11–20 of 111 posts
Re: What we learned about SSDs in 2015
#12...unless you are Fusion-io, in which case, most of these problems don't affect you.
Re: What we learned about SSDs in 2015
#13May 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.
And now we must rely on each OS to implement their own version of a virtual firmware, and do comparisons between different implementations, etc. etc. etc.
Re: What we learned about SSDs in 2015
#14At 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?
Even enterprise SSDs like Samsung's have a guarantee like "10 years or up to x TB of written data". So if you write a lot you can lose the guarantee after a year even with enterprise SSDs.
Re: What we learned about SSDs in 2015
#15At 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…
Just a note ... we use SSDs as write cache in ZFS at rsync.net and although you should be able to withstand a SLOG failure, we don't want to deal with it so we mirror them.
My personal insight, and I think this should be a best practice, is that if you mirror something like an SLOG, you should source two entirely different SSD models - either the newest intel and the newest samsung, or perhaps previous generation intel and current generation intel.
The point is, if you put the two SSDs into operation at the exact same time, they will experience the exact same lifecycle and (in my opinion) could potentially fail exactly simultaneously. There's no "jitter" - they're not failing for physical reasons, they are failing for logical reasons ... and the logic could be identical for both members of the mirror...
Re: What we learned about SSDs in 2015
#16...unless you are Fusion-io, in which case, most of these problems don't affect you.
why? isn't fusion-io based on ssd ?
Re: What we learned about SSDs in 2015
#17FWIW, the top-end HPE SSD models are rated for up to 25 writes of the entire SSD drive, per day, for five years.
The entry-level SSDs are rated for ~two whole-drive writes per week.
Wear gage, et al.
http://www8.hp.com/h20195/v2/GetPDF%2Easpx%2F4AA4%2D7186ENW%...
Re: What we learned about SSDs in 2015
#18At 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…
Just a note ... we use SSDs as write cache in ZFS at rsync.net and although you should be able to withstand a SLOG failure, we don't want to deal with it so we mirror them. My personal insight, and I think this should be a best practice, is that if you mirror something like an SLOG, you should source two entirely different SSD models - either the newest intel and the newest samsung, or perhaps previous generation int…
This is good advice, and fwiw the problem it addresses can happen in spinning drives too. We had a particular kind of WD drive that had a firmware bug where the drive would reset after 2^N seconds of power-up time (where that duration was some number of months).
Re: What we learned about SSDs in 2015
#19May 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.
The industry is moving toward a mid-point of having the flash translation layer still implemented on the drive so that it can present a normal block device interface, but exposing enough details that the OS can have a better idea of whether garbage collection is urgently needed: http://anandtech.com/show/9720/ocz-announces-first-sata-host...
Moving the FTL entirely onto the CPU throws compatibility out the window; you can no longer access the drive from more than one operating system, and UEFI counts. You'll also need to frequently re-write the FTL to support new flash interfaces.
Re: What we learned about SSDs in 2015
#20Kind 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…
Storage and CPU cycles aren't completely disjoint. While this is true for plain old data archival, a lot of storage in reality is just used as cache. You could argue even your customer data is a cache, because you can always go back to the customer for most of it. Most data can be recomposed from external sources given enough computation.