How well would a Ram Drive work in a Virtual Machine environment? If you have 12GB ram and give say 3GB to 2 virtual machines each and then used the other 6GB for the 2 cores not dedicated to the Virtual Machines....would a Quad Core run better that way? That would allow you to extend the Ram Disk in essence to greater then 3.5 and still stay free because you could make 3 on the same machine. I don't have the extended knowledge and number crunching abilities to come up with an efficiency or worthiness rating, but that would be one solution to having more then just 3.5GB for ram disk usage.

Edit: To clarify, I meant putting a ram disk in each of the virtual machine environments for a total of 3 over all on the single quad core scenario.

I am getting 97+ percent CPU efficiency on my quad-core when using FancyCache (write-cache only is sufficient), with 3 CEP2 jobs and a HPF2 job running. Before using the cache, I could only get about 96% on a single CEP2 job, due to the I/O limitations of my Gen 1 SSD, and it would go down to about 89 to 92 percent with 4 jobs running. I expect on a spinning platter drive it would reduce thrashing, but I have not tried it there. I have found that the "Disks" version of FancyCache is more stable than the "Volumes" version, but YMMV.

static uncompressed files are essentially part of a rolling ram disk in linux.

everything in linux that lives on a block device has a cache lifespan unless reads / writes are done expressly as raw.

so if you have more physical ram than disc, you are almost assured that you'r drive will be cached unless you have some really bizarre memory usage in a program.

ways to improve under linux:
use fdupes to hardlink -- my own experiment

on a platter you will get good results from running inside of a perhaps 8-gig contiguous extent loopback btrfs filesystem with compress option, without needing to do any serious OS reinstalling.

i think this would be something like





this volume remains in qextent.btrfs after reboot but if you use /tmp it WILL BE SWEPT after reboot

to use this setup after reboot/unmount



before boinc begins.

alternatively similar can be done on your swapfile by mounting ramzswap or tmpfs and running the queue inside swap or compressed swap., often with machines in a colo there's little reason NOT to do experiements on gigantic swapfs volumes :)

being on a small extent of disc obivous packs the data together on a less pathological range of fragmentation hardware access seeks.

swapfs is superior to other write overhead because there's no accounting or journaling, at the cost of RAM to other processes if you thrash it.

ramzswap is an option i have been curious about however you can have the same basic thing from btrfs with -ocompress so i have kept it simple.

i haven't tested a loopback mount arrangement yet, but on an ssd there's no point really.

Bearcat ubuntu or any other linux with 64 bits is as efficient as it gets standalone before tweaking advanced stuff.

so for the advanced stuff:

i have been crunching for maybe 2 weeks but

a) to improve seek times and match up your ram size to disc patterns: if you're not on a SSD and if you have 8 gigs of ram try running 8 gigs of max filfesystem space for your boinc-client as outlined above -- for 8 gigs of RAM create an 8 gig file with "dd", then move your queue data into it

if you can't squeeze all your BOINC data into the 8 gig loopback filesystem, be it by copmression or size alone, you can't roll 100% in RAM either.

b) to merge redundant queue files concurrently on fc12+ or ubu 10.10: with or without the loopback filesystem or running in tmpfs you can try to do it with fdupes. this WILL help with an SSD as well. (version of fdupes matters, see other thread https://secure.worldcommunitygrid.org/forums/...ead,30419_offset,0#304927 )

(paste into bash shell )

{ while fdupes -Lrnq /var/lib/boinc-client ; do sleep 600;done  } >/dev/null  & disown 

i dont have statistics or even know reliable metrics to measure before or after results but if you can run fdupes in a short amount of time (8 gigs oughta do it fine) you should be able to reduce IO waits between code running in the cpu.
.