[Nikker]

By relying on closed software on the Drives controller chips wouldn't it just get more complicated? With the price of RAM being as cheap as it is, why not just build a series of systems with 100GB+ of RAM and cache away?

Relying on a drive controller might seem the right way to go but especially for corporate installations I would believe it would be beneficial to have the fine grained control a dedicated server could provide.

[logicallee]

Because systems, including servers, don't expose an abstraction of being permanent (always-on) storage that never gets suddenly lost (rebooted, loses power) for any reason at any time. How could you run a laptop with a server inside that cached 100GB+ of RAM? You would have to wait for it to load from RAM. Not so with the device I outline: if it has 48 hours of trickle charge (my calculations could be wrong but apparently it just takes mere milliwatts to refresh a DIMM), then as long as it has received power in the last 48 hours it would be instant-on. Everything you do is instant, EVEN IF it's written against software that writes to permanent storage.

[bryanlarsen]

Sounds very much like the current suspend to RAM functionality that every laptop has, at great expense and complexity.

[logicallee]

only if you think having every disk access occur at ram speed rather than SSD speed makes no difference. CPU's and RAM are so fast, I think often in starting an application or the like, disk access really is the limiting factor. I suppose you can disagree. things like compilation could easily end up twice or five times as fast in my estimation. know anyone with a compilation in their workflow?

I should have said "C: drive"/"HDA1" but wrote boot media so I could save having to think about my phrasing. I meant that's where you would install anything that is primary to your workflow and might read and write lots of files, because that's how it was programmed, git, your ide, compiler, test suites, database, webserver and log files, or whatever programs you create and handle your workspace with, whatever that may be (photoshop, design software, etc).

the point is, things you would never risk not having on permanent storage, and which are written with the expectation that they will be. if it's ironclad (six/seven sigma, and backed up to real permanent storage behind the scenes in case worse comes to worst), you wouldn't have to give up this abstraction. it would still be a hard drive and not, you know, the current contents of your ram since you booted.

[Nikker]

I just can't seem to figure out where you are coming from on this. My first question is, why would you plug a device with transfer rates in the 20-40GB/s range into a SATA3(6Gpbs) port? Next is although we can wax poetically on what exactly is the best case for every ones use cases how are you going to guarantee that the micro controller will work the way you want it to? Databases with properly configured indexes will retain the important data in RAM with out further modifications, and again how would you ensure that the records you feel should be cached are cached since the small micro controller would barely have the resources to analyze the data stream to begin with.

Lastly if you do care about data retention during power outages and sags then you would likely want an APC/backup battery. Even though the data stored in the SSD/RAM hybrid might have enough backup power to flush to disk how about the data that is currently in RAM waiting to be flushed as well?

[bryanlarsen]

I still don't understand. If you have tons of RAM, your OS uses it for cache, so disk access is at RAM speed. I only reboot my computer a few times a year, so if I had 256GB of RAM in my computer everything I use at least once a month would be in cache.

[logicallee]

I doubt very much that this is the case. Your OS can't possibly report to, say, your database, that something is written, if in fact it is still being written. Likewise if your compiler produces a bunch of object files before linking them, your OS won't just stick them in RAM and say "well, there's your file, it's written" while not actually being written. I just don't think it works that way!

If it did, SSD's wouldn't be so much faster than spinning-platter HDD's...

[rzzzt]

A buffer cache in write-back mode would do this, but DBMSs are usually very strict when it comes to waiting for data to hit long-term storage. Most of the implementations access the disk directly, bypassing such mechanisms in the process.

http://www.tldp.org/LDP/sag/html/buffer-cache.html

[icebraining]

SSDs are still faster for non-cached reads, which are significant, since most people don't have as much RAM as they have of permanent storage.

By the way, what you're proposing in terms of software has been available for a long time; multiple distros (including Ubuntu) can/could be booted completely to RAM, using tmpfs as the filesystem. For example:

At the boot prompt, type "knoppix toram". Knoppix will load the contents of the CD into ram and run from there. After boot up, the CD can be removed and the cd drive will be available for other uses. Because this will take up a lot of ram, it is recommended for those with at least 1 GB of ram.

It's definitively faster, I just don't have the necessary RAM to fit all my system in there.