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 [EMAIL PROTECTED] out=result ... g.mapset mapset=$MAPSET g.copy [EMAIL PROTECTED],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 _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
