How to use a terabyte of RAM

This sounds like a good idea for embedded devices; they often have (or could cheaply have!)
much more RAM than flash storage.  Imagine something like a 4-500MHz ARM with 1G of RAM and 64
or 128M of flash.  Flash write speed actually *is* a limitation. 

the Violin box appears to the system like any other external SCSI device. it implements it's
own battery and backup mechinism, so ramback is not relavent to it.

I was wondering: is there a way to achieve something similar just using the I/O cache? 

My laptop is meant to run Vista and thus comes with 2GB of RAM, of which Linux (or even XP!)
does not use that much; it would be nice to tell the system to not flush some parts of the FS
to disk and keep them in RAM for a very long time, without having to set-up a RAM disk and
then committing it to disk on shut down...

More concretely: my source code is like so:

project/src/test/file_test_dir

all the file_test_dir's are big and contain big useless short-lived data. what is below is
important code. I'd love to be able to say: *test_dir does not be need be sync'd to disk at
all, or very rarely.

Ok, just writing it lets me think that's it's  not trivial unless I do create a RAM disk for
my test data... oh well.
Or maybe unionfs can help?

<q>Perhaps it's time for some wild ideas. And there is no better source for such ideas than
Daniel Philips,</q>

LOL; it's good to see Mr. Phillips is still at it after all these years. It's always good to
open the day to one of his trademark tome-like posts.

If the memory filesystem doesn't try to decide
on the order of writes to the underlying filesystem,
but instead simpley creates a queue of operations 
and feeds them to the disk in the order they
are received, then a logging filesystem can
reorder and coalesce them to get the physical
disk update quite quickly.

A colleague did a thesis on that, and found
that reordering and coalescing paid a huge
benefit.

Alternatively, one could have an intermediate
layer which the memory filesystem could pass
operations to, which could do optimizations like
doing all directory operations asap and in-order
and delaying all file writes until close or
a certain large size had accumulated, then
writing teh whole file in one fell swoop. The
latter is *very* effective at increasing performancw
while decreasing seeks and CPU usage.

--dave

When I suspend/resume my laptop (A Dell Inspiron E1505 that came pre-installed with Ubuntu,
since upgraded to x86-64 Kubuntu 7.10), about 10% of the time the keyboard and touchpad are
dead when it comes back.  The rest of the system is still working fine; if I press the power
button the "log out/suspend/hibernate/restart/turn off" dialog comes up (useless if I have no
mouse and keyboard), and if I plug in a USB mouse or USB keyboard I can use the system
normally.  (And if I suspend and resume it again via said USB peripherals, the
keyboard/touchpad controller usually revives itself when it comes back.)

If I don't happen to be carrying USB peripherals around with me, the only thing I can do is
hold the darn power button down until it hard powers off, and then reboot it.  I wind up doing
this, on average, about twice a month.

So there _is_ more to life than just trusting your battery...

You can get a remarkably similar effect today with tmpfs, in fact I'm writing this on a
root-on-tmpfs machine.  I store my root fs as a tar file so it can be read and written without
much disk seeking.  I have a paltry 8GB of RAM, but it's more than enough for the 2.7G rootfs,
which takes about a minute to load/dump.  It's dumped every night, and I even have apcupsd
start a dump when the power goes out.  I've been running this way since about November of 2005
with no problems, and it's FAST!