Suffering along on old hardware because the company budget doesn't include upgrades any time soon, I'm looking for ways to improve the performance of my builds and daily working routines. One thought that came to mind was to put all of my source into a RAM disk where it could build super-fast, but then there is the problem of keeping changes to the code safe on the actual hard disk.

Does anyone know of a way to set up a RAM disk that automatically saves writes of certain files back to the source hard disk?

I realize that the system cache does just this. Maybe there's a way to configure it more precisely to target certain areas?

Thanks,
Dave

From the title of your thread, I expected you should use a tmpfs (which is a ram file system backed by the swap partition).

But you have both a different request and a different definition of "disk-backed"

I think arranging for .o files and other intermediate files to be in a tmpfs rather than an ordinary file system would help a little.

But those are "disk-backed" in the overflow sense, not the security sense. So you wouldn't use it for anything that would be a disaster if lost during a system crash.

System crashes are rare. If you mean the same by "build" that I do, I don't think the loss of any current build products during a system crash is serious (even final build products, not just intermediate). After a system crash, I would restart any build from the beginning, not try to pick up where it left off.

I'm pretty sure that would not be worth all the trouble.

I'm pretty sure that is a bad idea.

That is the most important reason the above idea is bad. The system cache combined with an ordinary disk file system is fundamentally more effective at accomplishing what you want to accomplish with a disk backed ram file system.

That would be nice. I'd like to know that too. I think the potential extra benefits are pretty limited. The generic behavior is pretty good. I'd like to have more detailed control because that is my personality and I know I could do a little better. But I think that extra control isn't available and isn't really needed.

Thanks for the reply, Josh.

Yes, we generally agree on the fact that a system crash is rare enough to be overlooked and we can always start another build once we recover. I was definitely looking for something more general.

I considered tmpfs, and that would certainly take care of 90% of my problem. It's the fact that I'd be editing files in that space that need to be backed-up on a semi-regular basis (perhaps a cron task every few minutes using rsync) that makes this a bit unwieldy.

I primarily do Java development using Maven as my build system. So, from a multi-module point of view, my source and class files are somewhat mixed in the same directory tree. While possible, it's not convenient to try to separate them from each other. Hence, my curiosity about something that might be configurable. For instance, being able to tell the RAM disk to send copies of changes of *.java files back to the disk, but don't worry about backing up *.class files.

I've considered trying out a solid-state drive, but the expense is too high to justify it for an experiment. I was hoping that someone, somewhere along the way, had some up with something for Linux that might fill this little niche.

Maybe I'll give the tmpfs method a try for kicks. If I can squeeze some extra performance out of this aging Dell, it would be worth a little fiddling around.

Thanks again,
Dave