Hard Drive of the Future: Ram Drive

benzick writes "3d Retreat has posted a hands on look at a 2gig ram drive called the Rocket Drive. Article blurb: Overall the rocket drive is the best in I/O performance I have seen. It outperforms U160 SCSI drives by almost a factor of two. Yet there are some drawbacks to the Rocket drive, foremost is the price, although listed at the end of the review is some alternative pricing options to make it less expensive. And the rocket drive can not act as a boot drive. Also, if you have some extra money to spend, you can use multiple rocket drives in parallel."

Comments

Yes, but this one ...

[Tensor]

Keeps that data after the pc is turned off, which i bet your amstrad didn't do.

It has an external supply that keeps the card powered.

And i believe this is the whole point of this card, its pretty much useless otherwise.

Also the xfer speeds are limited to PCI (66mhz) speeds, that is why "its only" 2x as fast as a U160 scsi.

Not limited to 2 GB

[delta407]

The official website lists the capacity as 4 GB.

Re:Huh?

[at_18]

This tells you very little about the relative performance of the drives since image processing is typically not disk bound.

Actually, the author of the article made it disk bound, by forcing Photoshop to go into swap space with an image much larger than the available memory.
And you missed the HD testing pictures, measuring high throughput (sp?) and unbelievable low latency.

Useful as the ext3 journal

[Illusion]

If this had Linux drivers, it would be terribly useful for an external ext3 journal.

While profiling a high-volume qmail server with fast mirrored drives, I noticed that I could get at least an order of magnitude sustained mail throughput by eliminating the fsync() system call, which essentially forces the disk subsystem to stop whatever else its doing and get a few specific blocks all the way onto disk. You can't run it in production this way, as the SMTP RFC specifies that the mail must be actually on disk before the server can claim that its done.

The problem is that magnetic-media drives can only seek a few hundred times per second. Regardless of their claimed sustained throughput, if you are writing a bunch of small files to disk, you are completely dependent on the seek time of the drive.

But mounting a magnetic-media-based ext3 with data=journal and the journal on an NVRAM block device would essentially use this as a trusted write-cache. Linux will return from the fsync() system call as soon as the data is in the journal, which could happen instantly on an NVRAM disk as there is no seek time. It then reads from the journal in its spare time, sorts it to minimize seeks, and writes the data out to disk.

I suspect that this should offer roughly the same speed as eliminating the fsync()s entirely.

I was looking into ordering a similar product to test this. I found:

• http://www.imperialtech.com/products_megaram35.htm
• http://www.platypustechnology.com/20qikdrive.asp
• http://www.mncurtis.com/curtis/CurtisProducts/Clip perTwo.htm
• http://www.soliddata.com/products/datasheets/e100_ specs.html