Unfortunately it was a bad disk after all. Disk and head alignment was hard to do and we had lots of failures at the time. Of course technology changed and this can be solved now.

Now instead of spinning disk they use sliding and more heads. Wow!

Latency is a lost better than rotating disk, but not up to the best SSD standards. The oscillations are at about 800Hz which would give average (uncontended) random access times of about 0.6ms which is more than an order of magnitude worse than the best SSDs (but an order of magnitude better than rotating disks). It is impossible to get close to SSD latency figures on traditional shared storage protocols, so for the moment you do need direct bus attach to get the best out of these, but FC SANs are able to get latencies below 0.4ms, so these are a btter fit (we see write-to-array cache times of about 0.4ms measured from the device drive level).

With the need to fabricate millions of heads over quite large surface area (I think perhaps 100+ sq cm) at sub-micron level fabrication, then this is a considerable fabrication challenge. Of course the device is incredibly intolerant of differential expansion as if there were mis-registrations of anything like one micron over the width of the device then it would fail to work, but apparently the type of glass to be use has an expansion coefficient of less than one part in 10^9 per degree.

Producing a device like this cheaply and reliably (and making it reliable) is going to be a huge challenge, and even if they can get this down to that of a 15K FC drive (their aim), then there will be a point where the costs intersect with flash. We’ll see – an interesting approach, but the test will be when there is real product available. Certainly anything that can deal with the stuck-in-a-rut latency of enterprise drives at an acceptable cost is to be welcomed.

My guess (and given that they say “800Hz” and “oscillating”) is that the media is constantly vibrating. This provides a fixed addressing schedule, which greatly reduces the algorithm. Data is in linear tracks, with I believe a single head per track. So there aren’t any “settle times” per se – each head is always moving back and forth over its own track.

They can only currently have 64 heads performing IO simultaneously. So, they just need a 64-deep IO queue, and the controller never has to actually worry about activating too many.

I wonder if they can “read” the data backwards, blitting it into cache in the correct order? They must, for 800Hz to be equivalent to “96,000 RPM”.

Basically, all they need to do is keep their queue sorted by linear track offset of the request. Any time the media is nearing the offset of the next item in the queue, prepare that head to service it.

Hmm, I wonder if all bit regions are the same physical size? Or do they “stretch” in the middle where media velocity is higher. Certainly that’d be the simplest prototype approach, as the clock-time per IO would be the same everywhere (this is of course like CAV rotational media, eg HDDs).

As for scheduling, we concluded that while the magnitude of delays were certainly lower than those of disk drives (especially mobile drives), their behavior was very similar to that of disks. Since they are mechanical, positioning delays are distance dependent, favoring local access. Sequential access is preferred over non-sequential access because it is always most efficient to just keep on moving in the direction the media is already headed.

I don’t know any of the details of the Dataslide devices, obviously, so there may be differences from our conclusions. In particular, if the media is kept in resonance, then the device will behave even more like a disk — the heads will position horizontally and wait until the correct offset in the media arrives (“rotates”) into place. Our models assumed that the device has tighter control of both horizontal and vertical positioning. However, I can imagine that keeping the media constantly moving would make life simpler.

500MB/s = 4Gbps which is more than SATA-3, but less than (newly spec’d) SATA-6. Competition with SSDs is a Good Thing, though.

Being that this is still in the oven so to speak I’m guessing that their advantage over SSD may be size. Aren’t going to be looking at 500MB a sec from a single SSD (albeit high end) in the next few years?