[GRASS-dev] ramdisk as mapset?

[Hamish]

Hi,

* I have some scripts which are very heavy on raster map disk i/o.
   r.cost chugs heavily on the hard drive & the script can take days
   to loop through. I don't want to wear a hole in it if I don't have to.
* I have many GB of RAM to play with (enough to hold the region as DCELL)
* The raster modules typically don't use much ram at all. (low overheads
   to compete with for RAM)

I am trying to think of a way to get the raster ops to happen all in RAM
to save time & wear on the hard drive. (script spans a number of r.*
modules)

ideas so far:

1) [Linux] create a 2GB ramdisk using ramfs. use g.mapset to swich into
it, do the heavy i/o. switch back to the original mapset, g.copy the
results map back to the "real" mapset, then destroy the ramdisk.
advantages: easy to do.
disadvantages: it's more of a local hack than a general solution.

 mkdir /mnt/ramdrive

 # default max_size is 1/2 physical ram, auto-resizes 'til then
 mount -t ramfs none /mnt/ramdrive
 mkdir -p /mnt/ramdrive/tmp_mapset
 TMP_MAPSET="/mnt/ramdrive/tmp_mapset"
 ln -s "$TMP_MAPSET" $USER/grassdata/$LOCATION/tmp_mapset
 cp $USER/grassdata/$LOCATION/$MAPSET/WIND "$TMP_MAPSET"
 g.mapset mapset=tmp_mapset
 ...
 g.module in=map@$MAPSET out=result
 ...
 g.mapset mapset=$MAPSET
 g.copy result at tmp_mapset,result
 umount /mnt/ramdrive


problem: how to set group ID and mode/umask for ramdrive without
having to do chown+chmod as root?


2) Some backgrounded "grass_mapd" process to dynamically allocate and
hold a single map in memory. It's a child of the main GRASS process so
exiting GRASS tears it down. It could be a "virtual" map sort of like
how a reclass map is just a wrapper for something else. This is just a
very rough idea, probably not so easy to do; but if possible I reckon it
would be a cool tool to have.


anyone have ideas?

thanks,
Hamish