Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What we learned about SSDs in 2015

zdnet.com

Post reply on HN
Print view View original

71–80 of 111 posts

Re: What we learned about SSDs in 2015

#71

Post by wmf »

wtallis wrote: post #56
lsc wrote: post #43

Earlier quoted context omitted.

edit: okay, I re-read what you said and yes, these won't support M.2 drives, if I understand what's going on here, and it's possible I still don't. (I have yet to buy any non-sata SSD, though I will soon be making experimental purchases.) I was talking about these: http://www.supermicro.com/products/nfo/NVMe.cfm Note, though, it looks like if you are willing to pay for a U.2 connected drive, you can get 'em with the…

Take a look at how much stricter the temperature and airflow requirements are for Intel's 2.5" U.2 drives compared to their add-in card counterparts. (And note that the U.2 drives are twice as thick as most SATA drives.) M.2 has almost no place in the server market. U.2 does and will for the foreseeable future, but I'm not sure that it can serve the high-performance segment for long. It's not clear whether it will re…

OTOH if you can fit 24 U.2s but only 6 AICs in a server, maybe RAIDed U.2 will still win.

Re: What we learned about SSDs in 2015

#72

Post by bluedino »

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

Logging to flash storage is just asking for issues. We bought a recent model of LARGE_FIREWALL_VENDOR's SoHo product, and enabling the logging features will destroy the small (16GB?) flash storage module in a few weeks (!).

The day before we requested the 3rd RMA, the vendor put a notice on their support site that using certain features would cause drastically shortened life of the storage drive, and patched the OS in attempt to reduce the amount of writes.

Re: What we learned about SSDs in 2015

#73

Post by awqrre »

ComputerGuru wrote: post #8

Kind 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 is definitely the bottleneck for many applications and at one point in the past, it used to be the CPU that was the main bottleneck for these same applications so I can understand their point too.

Re: What we learned about SSDs in 2015

#74

Post by kijiki »

lsc wrote: post #65
wtallis wrote: post #56

Earlier quoted context omitted.

Take a look at how much stricter the temperature and airflow requirements are for Intel's 2.5" U.2 drives compared to their add-in card counterparts. (And note that the U.2 drives are twice as thick as most SATA drives.) M.2 has almost no place in the server market. U.2 does and will for the foreseeable future, but I'm not sure that it can serve the high-performance segment for long. It's not clear whether it will re…

>M.2 has almost no place in the server market. U.2 does and will for the foreseeable future, but I'm not sure that it can serve the high-performance segment for long. It's not clear whether it will reach the limits on capacity, heat, or link speed first, but all of those limits are clearly much closer than for add-in cards. No argument on m.2 - it's a consumer grade technology. No doubt, someone in the "cloud" space…

You're probably tired of hearing this from me, but if you distribute the storage, you can evacuate all the VMs off a host, down it, do whatever, bring it back up, and then unevacuate.

Re: What we learned about SSDs in 2015

#75

Post by djsumdog »

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…

I thought this was the point of SATA Expresses, but the last I read, SATA Express actually holds on par and even falls behind M.2.

Re: What we learned about SSDs in 2015

#76

Post by TD-Linux »

bluedino wrote: post #72
_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…

Logging to flash storage is just asking for issues. We bought a recent model of LARGE_FIREWALL_VENDOR's SoHo product, and enabling the logging features will destroy the small (16GB?) flash storage module in a few weeks (!). The day before we requested the 3rd RMA, the vendor put a notice on their support site that using certain features would cause drastically shortened life of the storage drive, and patched the OS i…

Logging to poorly specified Flash storage is the real problem. They were likely using a cheap eMMC flash, which are notorious for having extremely poor write leveling.

Unfortunately the jump to good flash is quite expensive, and often hard to find in the eMMC form factor which is dominated by low cost parts.

Re: What we learned about SSDs in 2015

#77

Post by TD-Linux »

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.

This has existed for a long time, see the Linux kernel's mtd infrastructure, and the filesystems designed to run on top of it (jffs, yaffs). It used to be used in a lot of embedded devices before eMMC became cheap, and is still used in things like home routers.

I am not sure how well mtd's abstraction fits with modern Flash chips, though.

Re: What we learned about SSDs in 2015

#78

Post by bigiain »

ersii wrote: post #66
burntwater wrote: post #54

Earlier quoted context omitted.

High-end video servers used in the entertainment industry typically use RAID 0. My last project, for example, used 10 250GB SSDs in RAID 0.

What kind of video servers are you talking about? For ingesting from a feed/camera in? Streaming out video? Curious.

A friend of mine does a lot of programming and installations using Dataton Watchout - where they use 4 or more 4K projectors stitched together into one big image. He's regularly got war stories about problems with the latest batch of SSDs not playing well in RAID0 causing stutters on simultaneous playback of multiple 4K video streams.

Re: What we learned about SSDs in 2015

#79

Post by bigiain »

dajonker wrote: post #36
tehwalrus wrote: post #29

Earlier quoted context omitted.

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

RAID 0 does not have any level of redundancy, so you might as well remove the 'R' in RAID and replace it by 'S' for striping or something. However, people would probably get confused if you start calling it SAID.

Complaining about industry-standard terminology like this is mostly a waste of time.

The sort of people who need to know that but don't aren't going to learn it from a post on HN, and the sort of people who'll read it on HN mostly don't need to be told.

Re: What we learned about SSDs in 2015

#80

Post by wtallis »

wmf wrote: post #71
wtallis wrote: post #56

Earlier quoted context omitted.

Take a look at how much stricter the temperature and airflow requirements are for Intel's 2.5" U.2 drives compared to their add-in card counterparts. (And note that the U.2 drives are twice as thick as most SATA drives.) M.2 has almost no place in the server market. U.2 does and will for the foreseeable future, but I'm not sure that it can serve the high-performance segment for long. It's not clear whether it will re…

OTOH if you can fit 24 U.2s but only 6 AICs in a server, maybe RAIDed U.2 will still win.

Only if you postulate that your drives won't be able to saturate their respective number of PCIe lanes. The total number of lanes in the system is fixed by the choice of CPU, and having drives with a total lane count in excess of that only helps when your drives can't fully use the lanes they're given or if you're trying to maximize capacity rather than performance.
Post reply on HN