Hacker News Reader

Comment by MrBuddyCasino | Hacker News Reader

> 1990 > SSD

Can you elaborate?

All of the early Cray mainframes (even the Cray-1 discussed here, although maybe only the somewhat later Cray-1/S) supported a "Solid State Disk" peripheral, which was basically a refrigerator full of RAM that was accessible via DMA channel. The intent was to be used to swap in and out large data sets from memory - I think even the early ones went up to a gigabyte in size.

I believe the idea also made its way to microcomputers (or was realized independently) shortly after, like with the SemiDisk:

https://web.archive.org/web/20201112040756/http://www.s100co...

Yes, the Cray Solid State Storage Device (SSD) was a standalone unit that looked like a quarter of a Cray, complete with bench. It held up to 2 gigabytes of data in MOS memory and was accessed via an I/O channel at 100 megabytes to 1.25 gigabytes per second. It was used for "temporary storage of datasets" and could "significantly increase data transfer rates." The SSD was separate from the Cray's main memory.

It is described in detail in the manual: http://www.bitsavers.org/pdf/cray/Disk/HR-0031_SolidStateSto...

> was accessed via an I/O channel at 100 megabytes to 1.25 gigabytes per second.

That's even faster than many modern SSDs.

It's my understanding that it wasn't a flash memory based SSD like we would see today, but just a huge amount of RAM (for its era) that could be used as storage. The facilities that typically hosted a Cray could be counted upon to have very reliable power, so the power failure risk of keeping stuff directly in RAM was low.

Rather you always had a back up generator that would let you shut down everything gracefully in the event of a power outage.

An uncle that worked in that area in the 80s/90s had stories about people who still argued these new fangled journaling file systems were pointless.

SGI machines had capacitor banks in the power supplies large enough to power the machine long enough for the kernel interrupt handler to park all of the hard drive write heads. It turns out that the voltage required to keep the write head writing is often less than the voltage required to keep RAM from corrupting. At least for a time, XFS journaling correctness relied on the kernel being able to prevent garbage writes on loss of power.

There used to be big caveats to using XFS on non-SGI hardware. Though, I think those caveats were roughly "XFS guarantees aren't much better than ext3/ext4 guarantees on power loss, on non-SGI hardware".

This isn't about a Cray, but it's roughly contemporaneous. According to https://trs.jpl.nasa.gov/handle/2014/26062, the Cassini space probe had an "SSD," and the contract to build it was awarded in 1992. It sounds like it was pretty much a RAM disk made from DRAM.

I'd imagine it would be practical to build and use something similar for a multi-million dollar supercomputer where cost is secondary to performance.

I have also seen mention of this in spacecraft design discussion. The concept being that for things which are powered from a radioisotope thermoelectric generator, it's safe to treat the RAM as storage.

Because there's absolutely no scenario after launch, in which the constant trickle of wattage flow from the RTG to the onboard DC distribution buses and computers would ever be interrupted.

If the power from the RTG were to ever be cut off it would be a catastrophic mission failure anyways, entirely aside from the power to the onboard computing systems being interrupted.

Presumably the OS would be in some nonvolatile medium and the SSD would only be used for stuff like storing sensor data anyway. In the event of corruption or a system restart you would lose all of your working data but could bootstrap the system again.

While it would make sense to have recovery routines in some nonvolatile memory to handle a system corruption use case, I'm not sure it if would be necessary for a system restart. IIRC, core-based systems had nonvolatile RAM, and I think at least some of them would continue to execute the same memory image after reset. I think the point of the GP was that one of these DRAM based recorders is basically nonvolatile for all intents in purposes in this application.

> I have also seen mention of this in spacecraft design discussion. The concept being that for things which are powered from a radioisotope thermoelectric generator, it's safe to treat the RAM as storage.

I don't buy it. They specifically design these systems with duplication in nature in case RAM gets corrupted by radiation in space. So you can't treat it as storage, but for very different reasons.

It was at the NSCEE (National Supercomputing Center for Energy and the Environment) installation at UNLV for Yucca mountain. There were two vector processors and an amazing 5GB SSD. The OS was UNICOS, a successor of System V and COS (Cray OS), and a user was actually fully swapped out on context switches.

The SSD wasn't new by any means. A decade earlier the Cray-1M optionally could have had an SSD.

To be clear, we're talking about battery-backed RAM (specifically MOS RAM) there, right?

I don't know how the solid state storage was implemented. There are bunches of Cray brochures on the Internet that might have that information.

It's not an SSD; they're referring to their main RAM as solid state storage to differentiate it from core memory.

I don't think it was battery backed by anything in the Cray, though I could be wrong. The general idea being that the Cray would be installed in a facility that should have massive whole AC circuit, true online type UPS, and generators backing that up.

I think they're talking about the (not battery backed) SRAM, that would have been referred to as solid state storage to differentiate it from core memory technology.

The gigabytes of SRAM used as main RAM you could stick on a Cray was a key differentiator for the platform (and would be still today).

I guess a RAM drive, where you aren't using mechanical methods for mass storage, can be considered a solid state drive

Even the Amiga had a RAM disk

RAM disk is the one thing I really miss on PC/Mac

You can easily setup a RAM disk on Windows at least.

These days with M2 SSDs it isn't really necessary and (as was the case back then) you are usually better off using any spare RAM for programs.

There are many software tools to give you a RAM disk these days on pretty much all major operating systems - even ones that give you a disk based off of GPU memory!

Has any of you actually successfully used a ramdisk recently on a modern GPU? The documentation available for doing this in Linux is pretty scarce.

Amiga had a nice trick called the RAD disk which was a ram disk whose content would be preserve across soft reboot

I think /dev/shm is available on most(?) Linux systems by default these days. I tend to use it instead of /tmp when I can.

On some distros, /tmp is a tmpfs (ramdisk) anyways. Which of course I discovered when building a package that was bigger than my installed memory (really big package on Arch Linux, which both mounts tmpfs there and then uses it as the default makepkg location).

I really hate this hack. It feels like an attempt by distro maintainers to make their distro feel and/or benchmark quicker than others. I don't know if that's the original reason it was done, but I do know that it's a big pain to work around for a program author. If I'm writing to /tmp, I expect that the file might be swapped to disk, and indeed that it will be paged to disk before the OOM killer comes for me. If what I wanted was named shared memory, I'd put it in /dev/shm.

What about /var/tmp ?

You can still create RAM disks with macOS. See `man diskutil`.

On most Linux /dev/shm is a RAM disk. Nothing to install even.

Has anyone seen a program actually put something here?

1990 is probably a little early for something flash-based, but battery-backed DRAM- and CCD-based devices existed before that.

Even Sinclair in the 80s had a prototype for the QL, which didn't go into production: http://www.computinghistory.org.uk/det/31270/Sinclair%20QL%2...

Reply on news.ycombinator.com