feature article
Subscribe to EE Journal Daily Newsletter
7 + 2 =

SSD Abstraction

Virtium Manages IIoT Solid-State Storage

Some memory technologies are straightforward. Like SRAM. You want to write a byte? You write a byte. You want to read a byte? You read a byte. Other than that, you have an on/off switch, and that’s pretty much it. OK, it’s expensive and uses power and – oh yeah – it’s volatile. But still – it’s so much simpler than the “cheaper” memories.

Like DRAM, which comes with all the refresh baggage.

Or flash. Yeah, let’s stop on this one, since it’s our topic for today. Flash memory has always required extra support anyway, even simply for managing the writing details. Traditional floating-gate flash pulls electrons into the eponymous floating gate via hot-electron injection, expelling them via Fowler-Nordheim tunneling. Simple enough, right?

Well, except that the oxide separating the floating gate from heavy traffic below gradually degrades, the more you exercise it. Even when pristine, stored electrons have some finite probability of tunneling out over time – giving rise to the “data retention” spec. But, with each write cycle, flaws start to appear in the oxide, making it easier for the stored electrons to leak out. This gives rise to the “endurance” spec: the number of times you can write before the resulting data retention will fall below spec.

So that leaves you with a problem: if you use a flash memory like any simple memory, you’re going to start writing at the bottom and move up (or the top and move down). You’re going to hit those first cells super often. The cells at the other end of the memory? They may never get hit. So some cells will wear out while others don’t wear at all. That sounds like a waste of memory! There must be a better way!

We would be throwing our thumb drives out a whole lot faster if it weren’t for the magic of “wear leveling.” Software (drivers or firmware) has to keep track of which cells have been written to more than others; the statistics are typically stored in special long-lived blocks in the flash chips. Using wear leveling, a new version of a piece of data is not likely to be overwritten on the old value (especially because you can erase only a block at a time, and you have to erase before rewriting). The next time you write a value for that cell, it will likely be mapped somewhere else that hasn’t been written as often.

It can get even more complex than this. Virtium says that they have 20 years of experience watching how different data-writing patterns affect memory life. So you can make your wear-leveling algorithms more sophisticated with such a complex model.

Going Up

Let’s move up a level in the architecture now, into a world where the basic unit of storage isn’t a flash cell or even a flash chip: it’s a solid-state drive (SSD). Let’s say that you’ve got a bunch of sensors in your industrial IoT (IIoT) setup, and they’re constantly sending data for storage. Some of that data you’re going to keep locally; some you’re going to push up to the cloud. However, if you request a data view from your phone app, any data – whether stored locally or in the cloud – should be viewable.

But here’s the thing: someone needs to manage where the data is stored on any of an array of SSDs in a rack somewhere. So bookkeeping is required to abstract away where a particular sensor’s data is located at any given time. Traditional single-chip wear leveling would have an address table only for a specific flash chip. So-called “global” wear leveling will manage all of the chips within a single SSD. But if

you have an array of SSDs, then you need to manage data across all of them.
And that’s one of the things that Virtium says that they do with their SSDs and accompanying software that, together, constitute their StorFly-IoT product. When sensors register on the system, software in a local gateway – vtEdge-IoT – assigns the storage location for the data as it comes in. Some of that data will go up to the cloud; other data won’t.

Meanwhile, vtView-IoT is a utility sitting in the cloud that allows you to monitor and manage the hard drives. From a simple data-usage standpoint, the software will display what it has in the cloud, polling the gateway for any local data being requested. So all of the data can be viewed without having to worry about what’s where.

Being of Sound Mind

That’s all well and good, but SSDs, like humans (and, less face it, like rotating media) are mortal. You can put them on a healthy diet and make them exercise all their cells, but, valiant though those efforts might be, you’re merely staving off the inevitable. At some point, your SSD will refuse to hold new data. (Or

it could accept data and promptly lose it. “And… It’s gone!” Your choice.)
How will that event be handled? Virtium monitors for the point where an SSD can no longer be written to, and, when that happens, it switches the SSD status from normal read/write to read-only. Exhausting the SSD doesn’t mean it can’t hold data; it means only that newly written data won’t likely last the full 10-year (or whatever) data retention spec. So whatever data is already in there should stick around for a while.

Which is convenient, since you can place a new SSD in the rack and copy the data over from the old SSD so that the new one picks up where the last one left off. You can then decommission the old one and remove it. This is largely an automated process.

And Stay Out!

But what about security? They tout this as yet another of their StorFly-IoT features (called vtSecurity-IoT). The first, and most obvious, aspect of this is encryption. Each SSD is built with a private key for AES-256 coding. The gateway software keeps track of the keys (presumably someplace inaccessible). When data is requested, each piece is individually decrypted; the whole assembled package is then re-encrypted for sending to the cloud.

In other security news:

• All software is attested
• Updates are done securely
• Each SSD is authenticated when plugged in. Their cloud software keeps track of which network nodes are trusted (like a registered SSD) or untrusted. An untrusted node isn’t allowed to access an SSD.
• They rely on an internal NXP security chip for protection against side-channel attacks.
• They monitor traffic constantly, looking for unusual behavior and patterns so that they can raise a flag if something looks off.
As suggested above, this is an industrial-oriented memory solution. Not likely to be making a showing in your home anytime soon. Well, unless you’re trying to start a new “manufacturing in your own home!” career option.

Oddly enough, StorFly-IoT hasn’t been formally announced; Virtium is doing a soft launch, and so we in the press are free to talk about it. But you’ll need to wait for full launch in a couple of months or so if you want to incorporate it into an IoT setup.

More info:
Virtium SSDs: IoT vs. IIoT

One thought on “SSD Abstraction”

Leave a Reply

featured blogs
Dec 11, 2017
This is a continuation of A Cadence Carol... before reading this post, be sure to have read the first four installments! Stave I: Moore’s Ghost, Part I and Part II Stave II: The First of the Three Spirits, Part I and Part II * * * * * Awaking in the middle of a prodigiou...
Dec 11, 2017
This time of year is typically set aside for preparation, and this year is no different. We spent November working on a couple of major upgrades to prepare for releases in 2018, one with the way we handle quotes in My Samtec, and the other with how we handle the checkout expe...
Nov 16, 2017
“Mommy, Daddy … Why is the sky blue?” As you scramble for an answer that lies somewhere between a discussion of refraction in gasses and “Oh, look—a doggie!” you already know the response to whatever you say will be a horrifyingly sincere “B...
Nov 07, 2017
Given that the industry is beginning to reach the limits of what can physically and economically be achieved through further shrinkage of process geometries, reducing feature size and increasing transistor counts is no longer achieving the same result it once did. Instead the...