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

41–50 of 111 posts

Re: What we learned about SSDs in 2015

#41

Post by TeMPOraL »

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…

Ever tried to play a modern computer game? You never have enough RAM for stuff; a lot of content gets dumped onto hard drive sooner or later (virtual memory), or is be streamed from the drive in the first place. Having faster access helps tremendously.

From my observation, actually most personal and business use machines are IO-bound - it often takes just the web browser itself - with webdevs pumping out sites filled with superfluous bullshit - to fill out your RAM completely, and then you have swapping back and forth.

Re: What we learned about SSDs in 2015

#42

Post by wtallis »

lsc wrote: post #37
wtallis wrote: post #23

Earlier quoted context omitted.

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…

most of the NVMe backplanes I've seen give full 'enterprise 2.5" drive clearance to the thing, so if they are actually as thick as consumer SSDs, as most current SATA 'enterprise SSD' are, there's plenty of room for a heatsink without expanding the slot. The supermicro chassis (and I've only explored the NVMe backplanes from supermicro) usually put a lot of effort into drawing air through the drives, so assuming you…

You need to be more precise with your terminology. There is no such thing as a NVMe backplane. NVMe is a software protocol. The backplanes for 2.5" SSDs to which you refer would be PCIe backplanes using the SFF-8639 aka U.2 connector. None of the above is synonymous with the M.2 connector/form factor standard, which is what I was talking about.

Re: What we learned about SSDs in 2015

#43

Post by lsc »

wtallis wrote: post #42
lsc wrote: post #37

Earlier quoted context omitted.

most of the NVMe backplanes I've seen give full 'enterprise 2.5" drive clearance to the thing, so if they are actually as thick as consumer SSDs, as most current SATA 'enterprise SSD' are, there's plenty of room for a heatsink without expanding the slot. The supermicro chassis (and I've only explored the NVMe backplanes from supermicro) usually put a lot of effort into drawing air through the drives, so assuming you…

You need to be more precise with your terminology. There is no such thing as a NVMe backplane. NVMe is a software protocol. The backplanes for 2.5" SSDs to which you refer would be PCIe backplanes using the SFF-8639 aka U.2 connector. None of the above is synonymous with the M.2 connector/form factor standard, which is what I was talking about.

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 giant heatsinks you want:

http://www.pcper.com/news/Storage/Connector-Formerly-Known-S...

further edit:

http://www.intel.com/content/dam/www/public/us/en/documents/...

available; not super cheap, but I'm not sure you'd want the super cheap consumer grade stuff in a server, anyhow.

further edit:

but I object to the idea of putting SSDs on PCI-e cards for any but disposable "cloud" type servers (unless they are massively more reliable than any that I've seen, which I don't think is the case here.) just because with a U.2 connected hard drive in a U.2 backplane, I can swap a bad drive like I would swap a bad sata drive; an alert goes off and I head off to the co-lo as soon as convenient and I can swap the drive without disturbing users, whereas with a low-profile PCI-e card, I've pretty much gotta shut down the server, de-rack it, then make the swap, which causes downtime that must be scheduled, even if I have enough redundancy that there isn't any data loss.

Re: What we learned about SSDs in 2015

#45

Post by fleitz »

scurvy wrote: post #34
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...

My thoughts exactly. The article is quite inflammatory and tosses out some bold statements without really deep diving into them. My favorite: "Finally, the unpredictable latency of SSD-based arrays - often called all-flash arrays - is gaining mind share. The problem: if there are too many writes for an SSD to keep up with, reads have to wait for writes to complete - which can be many milliseconds. Reads taking as lon…

There is unpredictablilty in SSDs however, its most like whether an IOP will take 1 ns or 1 ms, instead of 10 ms, or 100 ms with an HD.

The variability is an order of magnitude greater but the worst case is an is several orders of magnitude better. Quite simply no one cares that you might get 10,000 IOPS or 200,000 IOPS from an SSD when all you're going to get from a 15K drive is 500 IOPS

Re: What we learned about SSDs in 2015

#46

Post by acquacow »

jjtheblunt wrote: post #38
ddorian43 wrote: post #16

Earlier quoted context omitted.

why? isn't fusion-io based on ssd ?

fusion-io (i believe, but please verify online) uses a spinning drive for frequent writes and an ssd for frequent reads, with software deciding what goes where, lessening the write traffic to the ssd, and thus wear to it.

No, Fusion-io has nothing to do with spinning drives. They make PCI-e flash drives with an FPGA as the "controller" for the flash. There are multiple communication channels, so you can simultaneously read and write from the drives, and there are various tunings available to control how garbage collection works. They are the only "SSD" that doesn't hide all the flash behind any kind of legacy disk controller or group protocol like NVMe

Re: What we learned about SSDs in 2015

#47

Post by acquacow »

ddorian43 wrote: post #16
acquacow wrote: post #12

...unless you are Fusion-io, in which case, most of these problems don't affect you.

why? isn't fusion-io based on ssd ?

They use flash like all other SSDs, but don't use a disk controller or any community defined protocols for mass compatibility. They use their own software and an FPGA to control the flash.

Re: What we learned about SSDs in 2015

#48

Post by toomuchtodo »

lsc wrote: post #35
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.

uh, this shouldn't be voted down. Now, I don't use RAID for performance, I use raid for reliability, like parent said, and I've never actually been in a position where it would make sense, but people do use raid0 to increase performance. It happens, even if it's not nearly as common as using raid to prevent data loss.

Back in the day, folks would RAID0 AWS EBS volumes to get the level of performance they needed (this was long before SSD EBS volumes).

Re: What we learned about SSDs in 2015

#49

Post by nostrademons »

ak217 wrote: post #40

This article has a lot of good information, but its weirdly sensationalistic tone detracts from it. I appreciate learning more about 3D Xpoint and Nantero, but SSDs are not a "transitional technology" in any real sense of the word, and they won't be displaced by anything in 2016, if nothing else because it takes multiple years from volume capability to stand up a product pipeline on a new memory technology, and more…

I got the sense that it was a PR hit for Nantero, bought and paid for. Notice the arc of the article: it says "[Popular hot technology] is dead. [Big vendors] have recently introduced [exciting new product], but [here are problems and doubts about those]. There's also [small startup you've never heard of] which has [alternative product] featuring [this list of features straight from their landing page]."

Usually these types of articles are designed to lead people directly to the product that's paying for the article. Sensationalistic is good for this; it gets people to click, it gets people to disagree, and then the controversy spreads the article across the net. Seems like it's working, in this case.

Re: What we learned about SSDs in 2015

#50

Post by wtallis »

pkaye wrote: post #33
wtallis wrote: post #31

Earlier quoted context omitted.

Discard operations only tell the drive that a LBA is eligible for GC. It's basically a delete operation that explicitly can be deferred. It does not give the OS any input into when or how GC is done, and it doesn't give the OS any way to observe any details about the GC process. I think the recommendations for periodic fstrim of free space is due to filesystems usually not taking the time to issue a large number of d…

SATA drives until recently didn't have queued trims so if you did an occasional trim between read/writes you would have to flush the queue. Queued trims were added later on but have been slow to be adopted because it can be difficult to get it working fast, efficient and correct when intermingled with reads and writes. I know atleast one recent drive with queued trim had some bugs in the implementation.

Yeah, SATA/AHCI's limitations and bugs have affected filesystem design and defaults, to the detriment of other storage technologies. NVMe for example requires the host to take care of ordering requirements, so basically every command sent to the drive can be queued.
Post reply on HN