Are solid-state drives good enough to stop worrying about disk IO bottlenecks?

Question

I've got a proof-of-concept program which is doing some interprocess communication simply by writing and reading from the HD. Yes, I know this is really slow; but it was the easiest way to get things up and running. I had always planned on coming back and swapping out that part of the code with a mechanism that does all the IPC(interprocess communication) in RAM.

With the arrival of solid-state disks, do you think that bottleneck is likely to become negligible?

Notes: It's server software written in C# calling some bare metal number-crunching libraries written in FORTRAN.

Answer 1

I think that you will find the bottlenecks are just moved. As we expect higher throughput then we write programs with higher demands.

This pushes bottlenecks to buses, caches and parts other than the read/write mechanism (which is last in the chain anyway).

With a process not bound by disk I/O, then I think you might find it becomes bound by the scheduler which limits the amount of read/write instructions (as with all process instructions).

To take full advantage of limitless I/O speed you would require real-time response and very aggressive management of caches and so on.

When disks get faster then so does RAM and processors and the demand on devices. The bottleneck is the same, the workload just gets bigger.

Answer 2

I don't believe that it will change the way I/O bound applications are written the tiniest bit. Having faster processors did not make people pick bubblesort as a sorting algorithm either.

The external memory hierarchies are an inherent problem of computing.

Answer 3

Joel on Software has an article about his experience upgrading to solid state. Not exactly the same issue you have, but my takeaway was:

Solid state drives can significantly speed up I/O bound operations, but many things (like compiling) are still cpu-bound.

Answer 4

The short answer is probably no. A famous researcher named Jim Gray gave a talk about storage and performance which included this great analogy. Assuming your brain as the processor, accessing a register takes 1 clock tick (numbers on left) which roughly equivalent to that information being in your brain. Accessing memory takes 100 clock ticks, so roughly equivalent to getting data somewhere in the city you live in. Accessing a standard disk takes roughly 10^6 ticks, which is the equivalent to the data being on pluto. Where does solid state fit it? Current SSD technology is somewhere between 10^4-10^5 depending on who you ask. While they can be an order of magnitude faster, there is still a tremendous gap between reading from memory and reading from disk. This is why the answer to your question is likely no, since as fast as SSDs become they will still be significantly slower than disk (at least in the foreseeable future).

Answer 5

but it was the easiest way to get things up and running. I usually find that it's much cheaper to think good once with your own head, than to make the cpu think millions of times in vain.

Answer 6

Solid state drives do make one important improvement to IO throughput, and that is the fact that on solid state disks, block locality is less of an issue from rotating media. This means that high performance IO bound applications can shift their focus from structures that arrange data accessed in order to structures that optimize IO in other ways, such as by keeping data in a single block by means of compression. That said, Even solid state drives benefit from linear access patterns because they can prefetch subsequent blocks into a read cache before the application requests it.

A noticeable regression on solid state disks is that writes take longer than reads, although both are still generally faster than rotating drives, and the difference is narrowing with newer, high end solid state disks.

Answer 7

I have a solid-state drive, and no, this won't eliminate I/O as a bottleneck. The SSD is nice, bit it's not that nice.

It's actually not hard to master your system's IPC primitives or to build something on top of TCP. But if you want to stick with your disk stuff and make it faster, ramdisk or tmpfs might do the trick.

Answer 8

No, sadly not. They do make it more interesting though: SSD drives have very fast reads and no sync time, but their writes are almost as slow as normal hard drives. This means that you will want to read most of the time. However when you do write to the drive you should write as much as possible in the same spot since SSD drives can only write entire blocks at a time.

Answer 9

No. Current SSDs are designed as disk replacements. Every layer, from SATA controller to filesystem driver treats them as storage.

This is not a problem of the underlying technology, NAND flash. When NAND flash is directly mapped into memory, and uses a rotating log storage system instead of a file system based on named files it can be quite fast. The fundamental problem is that NAND Flash only performans well in block updates. File metadata updates cause expensive read-modify-write operations. Also, NAND blocks are much bigger than typical disk blocks, which doesn't help performance either.

For these reasons, the future of SSDs will be better cached SSDs. DRAM will hide the overhead of poor mapping and a small supercap backup will allow the SSD to commit writes faster.

Answer 10

How about using a ram drive instead of the disk? You would not have to rewrite anything. Just point it to a different file system. Windows and Linux both have them. Make sure you have lots of memory on the machine and create a virtual disk with enough space for your processing. I did this for a system that listened to multiple protocols on a network tap. I never new what packet I was going to get and there was too much data to keep it in memory. I would write it to the RAM drive and when something was completed, I would move it and let another process get it off the RAM drive and onto a physical disk. I was able to keep up with really busy server class network cards in this way. Good luck!

Answer 11

Something to keep in mind here:

If the communication involves frequent messages and is on the same system you'll get very good performance because Windows won't actually write the data out in the first place.

I've had to resort to it once and discovered this--the drive light did NOT come on at all so long as the data kept getting written.