Posts by TheSolderMonkey 14 publicly visible posts • joined 4 Oct 2016
Well you're right, spinning media won't hang around for long when SSDs reach price parity with it.
And density parity.
And the wear out issues are solved.
Until all of that happens, spinning rust will remain mainstream and industrial SSD use cases will stay niche.
As for the forecast that SSD revenue will overtake spinning, well that sounds like cobblers to me. El Reg should have quoted Russell Grant, he's a professional fortune teller you know.
Great product, but what's the real world use case?
It's a JBOD, there is no data protection, no teiring, no thin provisioning, no compression, no encryption, no applications written to make use of it, no sun no moon! No morn no noon! No dawn no dusk, no proper time of day. No viable market.
I can think of maybe three customers...
* CERN, for capturing data from those big collectors.
* Lawernce Livemore and other extreme compute farms.
* Nope, really can't think of a third. Not even Watson could make use of this.
There are very few use cases that need this many IOPs over a relatively small dataset that can accept the lack of data protection.
Really great product though, let's hope it's not E8's November.
Yeah, I know I'm not the first on this list to say this. The others were more cryptic.
Technically I guess the company are correct. If the de-linked website says "fraud" and the company are not being investigated for "fraud" then the website is libellous. Whether or not they are being investigated for any other legally different offence is irrelevant in the eyes of the law.
Is this the ruling? I don't speak enough German.
https://www.lhr-law.de/wp-content/uploads/2017/06/Beschluss-OLG-M%C3%9C-Lumen-geschw.pdf
If I were Google I'd have headed this off at the pass. A quiet word with the owner of the offending website to get the article changed so that the offence under investigation was correctly defined would have saved Google from a dangerous court precedent AND been a healthy two fingers to the company in question.
Er, yeah, OK.
Let's think about that. My current tool set is:
Freescale codewarrior.
Lattice Diamond.
Green Hills Multi
Cypress PSoC creator.
Cadence ORCAD / Allegro.
Texas Instruments BQ Eval, Battery management studio & TINA.
IDT Timing commander
Xgig Analyser
Eagle & KiCAD.
GreenPAK designer
PLX SDK.
etc. etc.
I don't use an OS, I use the tools that run on the OS. I give not a poop about the OS itself, provided it is functional and stable.
I'm a hardware designer. I'm using tools developed by chip vendors to allow me to poke around inside their chips. The tools are generally ONLY written for Windows, because that's what everyone has.
I *could* run Windows in a VM under Linux. But I would spend my entire day in the VM. The Linux layer wouldn't add much to my experience. The VM is an unwanted extra layer of complication.
I don't condone or even like what Microsoft are doing. The truth is I hate the direction they are taking their company. I want to buy software, not rent it. And they can copulate freely with themselves if they think I'm going to voluntarily sign up for W10's snooping.
So I'm on W7 and will remain so. When I need new hardware, I guess I'll the only option will be W7 under a VM, it's not something I'd want. It's just the least unpalatable option.
Interesting stuff.
Uses standard PHYs, I assume they mean SERDES,
Well that means point to point links, and switches rather than the bussed architecture in the slide deck.
But switches will add latency.
Multi host.
So no root complex like PCIe, or connection via non transparent bridges?
Works with unmodified OS.
So I'm guessing it doesn't properly support hot plug / unplug then. Because standard OSes don't take kindly to having their memory maps shifting beneath them like sand in the wind.
I hope that hot plug gets integrated properly. Sounds like a very interesting project. If any of the cooperating partners are looking for a hardware development engineer with 20+ years experience designing storage systems, there's a very good chance that I'll be laid off today and this sounds like an exciting project.
[/hopeful shot in the dark]
The disks are faster than the controllers. If you start popping RAID levels on a stripe of disks, the controller quickly kills the performance of the SSDs. Especially with something like RAID 6 which uses a crazy number of read-shift-xor-write operations.
Raid 1 doubles the cost of an already expensive medium.
I think you may be missing the point.
The drive with a bad block may or may not give a warning via SMART, that's irrelevant.
The problem is that an desktop drive will realise that it's having problems reading the sector that the controller has asked for and will retry many many times. This effectively stalls that drive for seconds at a time. If the drive is part of a stripe, stripe operations can stall too.
In the desktop environment, the user would want the drive to do everything to get the data back. Because you only have a single user, so what if things slow a little? That file could be a picture of fluffy kittens or something of equally life changing import.
In an array, why the hell would you want a disk to attempt ERPs? You can rebuild the bad block from other disks in a fraction of the time that the single disk can do it's ERPs.
You want the single disk to fail as quickly as possible. You quickly reconstruct the data, and write verify it back to the single disk. If the single disk fails to write, the block gets added to the G list and reallocated.
It's not really about reliability, the article isn't great in that respect. It's about response time. The actual bit error rates and FIT rates aren't a hell of a lot different between enterprise and desktop drives. But the response of a drive to an error is very different.
That's the main difference between and enterprise drive and a desktop drive.
The desktop drive does everything it can to recover your data - response time be damned, whereas the enterprise drive does everything it can to meet the response time, data recovery be damned.
Sounds like Google (and some journos) are leaning storage 101.
We're off topic, this is surprise removal of PCIe. Hot un-plug. NVMe is essentially a protocol running on PCIe.
Its ingrained behaviour at many levels, from the PCI protocol (some of this stuff goes waaay back beyond PCIe).
The physical and electrical layers really don't care about surprise removal. You'll do no harm to the cabling or the PHYs.
All of the other layers of PCIe kinda get their knickers twisted with surprise removal. The protocol isn't really designed to deal with stuff going missing. PCIe is essentially memory mapped 'stuff'. PCIe has strict rules about what types of traffic can overtake other types of traffic. If something goes missing lower down in the tree, then the root complex can stall because new transactions are queued behind the transaction that will never complete. So hot unplug can make things fall over in a heap.
Hot plug presents a different set of problems. BIOSes (or is it BIOI?) weren't designed to cope with a shifting memory map. They scan the PCIe infrastructure once during the reset sequence and build a memory map based on what's there. Surprise insertion isn't possible with standard kit, the BIOS won't have allocated space in the memory map for the NVMe drive that you have just hot plugged into your stable running system. BIOS doesn't know about it, it's not in the memory map and the OS running on top doesn't stand a chance - let alone the apps running on the OS.
So there is a new breed of PCIe switches that are capable of faking end points when they're not present.
The switches track transactions to the endpoint and ensure that the root complex always gets a valid completion even if the end point has been unplugged. The root complex won't get valid data and will have to deal with that, but at least the PCIe infrastructure doesn't gum itself up.
These new switches are also capable of faking a device at the bus scan. So if you have a chassis with an NVMe slot, and the slot is empty at power on, the switch will pretend that the slot is filled when the root complex does it's bus scan. So BIOS will map the device into memory and everyone is happy.
Almost. The OS still needs to know that the device is not actually there and the switch needs to know in advance what type of device you'll be plugging in.
So I guess you can see why these new fancy switches aren't cheap. NVMe offers some fantastic advantages over SAS, but building an enterprise system with ain't easy. An enterprise system means dual paths to every disk, ruling out M.2 . It means hot pluggable (and worse hot unpluggable) media. Doing this for NVMe means hardening a protocol that simply wasn't designed to support hot swap, then hardening the BIOS, then the OS and possibly the application too.
It's not impossible, its just one of the things that makes my life fun. :)
Redundancy.
The M.2 format only has a single host connection. U.2 or SFF8639 as it's much better known has two host connections.
You can't build an enterprise system with M.2 decives because you can attach two controllers and all enterprise systems have two controllers for redundancy.
It's perfectly possible to build a hot pluggable M.2 with Sata or NVMe, but the later is far more complicated. Host systems don't like their PCIe reads to go missing. If a read doesn't complete, PCIe buffer credits are consumed and the entire PCIe infrastructure crashes.
Companies like PLX and PMC Sierra (now MicroSemi & MicroSemi respectively, how the hell did that get through monopolies and mergers?) offer PCIe switches with integral read tracking. The switch will fake read completion in the case of surprise removal. The chips will also fake a device as being present at bus scan time, so that you can deal with parts being added after boot time. They are of course chuffing expensive bits of silicon.
Finally Xyratex (now Seagate, soon to be gone) did make a drive for enterprise boxes that had a U.2 front end and multiple M.2 devices inside. I don't know how well it sold.
If anyone is wondering, yes, I am an enterprise storage box designer.
SVC and it's renamed derivatives are as relevant today as they ever were. Like every all flash controller, when you fill them full of SSDs the controllers will struggle to keep pace with the disks, especially true if you ask the controller to give you more sensible protection than RAID 1. This is not an IBM only problem.
Within IBM there has long been a struggle as to which product should fill the enterprise space. DS8K is currently the top dog. SVC (yeah, they renamed it) would be capable of filling that space, but lacks a key host interface required by System Z. SVC Development at Hursley have never looked to add this feature, leaving SVC targeting the mid range and leaving the Tuscon boys the DS8K and the enterprise market.
XIV isn't high end, XIV is just, different.
It is no secret that the SVC team were originally responsible for the disk controller cards and firmware that ran in the enterprise products (DS8000, DS800 and older stuff - SSA was invented by this team). Neither is it a secret that SVC stole some code from enterprise boxes.
You can sling mud at the SVC family, but largely its a decent bit of software. The development team have a right to feel proud of their achievements.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
