What we learned about SSDs in 2015 • Hacker News Board

Re: What we learned about SSDs in 2015

#21

Post by nly » Sun, Dec 20, 2015, 5:49 PM UTC

pkaye wrote: post #5

exabrial wrote: post #2

Does 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 differenc…

> You could for example move the handling of some of these GC details to the OS filesystem level

Isn't this basically the Linux 'discard' mount flag? Most distros seem to be recommending periodic fstrim for consumer uses, what's the best practice in the data center?

Re: What we learned about SSDs in 2015

#22

Post by velox_io » Sun, Dec 20, 2015, 5:58 PM UTC

The most exciting recent development in SSDs (until 3DXpoint is released), is bypassing the SATA interface, connecting drives straight into the PCIe bus (no more expensive raid controllers). Just a shame hardly any server motherboards come with M.2 slots right now.

The 4x speed increase and lower CPU overhead means it is now possible to move RAM only applications (for instance in-memory databases) to SSDs, keeping only the indexes in memory. Yeah, we've been going that way for a while, just seems we've come a long way from expensive Sun e6500's I was working with in just over a decade ago.

Re: What we learned about SSDs in 2015

#23

Post by wtallis » Sun, Dec 20, 2015, 6:16 PM UTC

velox_io wrote: post #22

The most exciting recent development in SSDs (until 3DXpoint is released), is bypassing the SATA interface, connecting drives straight into the PCIe bus (no more expensive raid controllers). Just a shame hardly any server motherboards come with M.2 slots right now. The 4x speed increase and lower CPU overhead means it is now possible to move RAM only applications (for instance in-memory databases) to SSDs, keeping on…

M.2 slots don't make much sense for servers, at least if you're trying to take advantage of the performance benefits possible with a PCIe interface. Current M.2 drives aren't even close to saturating the PCIe 3.0 x4 link but they're severely thermally limited for sustained use and they're restricted in capacity due to lack of PCB area. Server SSDs should stick with the traditional half-height add-in card form factor with nice big heatsinks.

Re: What we learned about SSDs in 2015

#24

Post by seabrookmx » Sun, Dec 20, 2015, 6:23 PM UTC

japaw wrote: post #11

"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...

Yeah I thought that too. I think the author is specifically referring to 2.5" form factor SATA SSD's though.

Re: What we learned about SSDs in 2015

#25

Post by tw04 » Sun, Dec 20, 2015, 6:38 PM UTC

velox_io wrote: post #22

The most exciting recent development in SSDs (until 3DXpoint is released), is bypassing the SATA interface, connecting drives straight into the PCIe bus (no more expensive raid controllers). Just a shame hardly any server motherboards come with M.2 slots right now. The 4x speed increase and lower CPU overhead means it is now possible to move RAM only applications (for instance in-memory databases) to SSDs, keeping on…

How exactly does connecting to the PCIe bus obviate the need for RAID? RAID isn't about connecting drives, it's about not losing data. If you don't need RAID for your application today, you can purchase a non-RAID SAS adapter for a couple hundred bucks, or just use the onboard ports that are sure to be there.

Re: What we learned about SSDs in 2015

#26

Post by nqzero » Sun, Dec 20, 2015, 6:48 PM UTC

wtallis wrote: post #19

vbezhenar wrote: post #9

May 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; yo…

OS compatibility is important for laptops/desktops, but not in at least some database / server applications, and those are the applications that would benefit most from raw access

Re: What we learned about SSDs in 2015

#27

Post by andrepd » Sun, Dec 20, 2015, 6:55 PM UTC

_ak wrote: post #6

At 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…

In a sense, so is all storage hardware. It's just a matter of how long it takes before it fails. This goes for SSDs, HDDs, Flash cards, etc.

Re: What we learned about SSDs in 2015

#28

Post by scurvy » Sun, Dec 20, 2015, 6:55 PM UTC

stefantalpalaru wrote: post #4

transfire wrote: post #3

Not 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.

I think transfire was referring to RAM in the system to act as a pagefile read cache, not RAM on the SSD to act as a cache there. There's no power risk to an OS-level read cache.

Re: What we learned about SSDs in 2015

#29

Post by tehwalrus » Sun, Dec 20, 2015, 6:55 PM UTC

tw04 wrote: post #25

velox_io wrote: post #22

The most exciting recent development in SSDs (until 3DXpoint is released), is bypassing the SATA interface, connecting drives straight into the PCIe bus (no more expensive raid controllers). Just a shame hardly any server motherboards come with M.2 slots right now. The 4x speed increase and lower CPU overhead means it is now possible to move RAM only applications (for instance in-memory databases) to SSDs, keeping on…

How exactly does connecting to the PCIe bus obviate the need for RAID? RAID isn't about connecting drives, it's about not losing data. If you don't need RAID for your application today, you can purchase a non-RAID SAS adapter for a couple hundred bucks, or just use the onboard ports that are sure to be there.

> RAID isn't about connecting drives, it's about not losing data.

RAID-0 is used as a way to get faster performance from spinning disk drives, as you can return parts of each read request from different (striped) drives.

You also get better write performance, as your writes are split across the drives.

Re: What we learned about SSDs in 2015

#30

Post by scurvy » Sun, Dec 20, 2015, 6:57 PM UTC

wtallis wrote: post #23

velox_io wrote: post #22

The most exciting recent development in SSDs (until 3DXpoint is released), is bypassing the SATA interface, connecting drives straight into the PCIe bus (no more expensive raid controllers). Just a shame hardly any server motherboards come with M.2 slots right now. The 4x speed increase and lower CPU overhead means it is now possible to move RAM only applications (for instance in-memory databases) to SSDs, keeping on…

M.2 slots don't make much sense for servers, at least if you're trying to take advantage of the performance benefits possible with a PCIe interface. Current M.2 drives aren't even close to saturating the PCIe 3.0 x4 link but they're severely thermally limited for sustained use and they're restricted in capacity due to lack of PCB area. Server SSDs should stick with the traditional half-height add-in card form factor…

2.5" NVMe is fine and more scalable than add-in cards (more slots) with increased serviceability. The equivalent add-in card is usually much more expensive than the 2.5" version.