[GRASSLIST:4142] Re: Map import cluelessness

Glynn Clements glynn.clements at virgin.net
Tue Aug 10 01:00:55 EDT 2004


C.S. Cornuelle wrote:

> Thanks for the succinct description.  It allowed me to get as far
> as i.rectify, where this ancient (according to some web searching) 
> problem arose courtesy of my mailbox:
> 
> 	GIS ERROR: error while writing to temp file
> 
> As per a recommendation I tried this:
> 
> 	watch df -h 
> 
> and then some of this:
> 
> GRASS:/data/grassdata > date;df /data
> Mon Aug  9 17:02:19 MDT 2004
> Filesystem           1K-blocks      Used Available Use% Mounted on
> /dev/hdb4             24590712  11836772  12753940  49% /data
> GRASS:/data/grassdata > date;df /data
> Mon Aug  9 17:02:34 MDT 2004
> Filesystem           1K-blocks      Used Available Use% Mounted on
> /dev/hdb4             24590712  11026744  13563968  45% /data
> 
> While the first call of df /data probably did not catch peak disk 
> usage, the difference is around 810M, not nearly large enough to 
> fill the disk or the partition.  
> 
> Any ideas on what might be going on here?  Is there a malloc set 
> in i.rectify which is causing this?  FYI this map has 7500 rows and
> 15600 columns, so it is rather large.  10 points were identified in
> i.points, and the rms value was somewhat high, nearly 100.  

On 32-bit architectures (e.g. x86), files are limited to 2Gb; it may
be that you are exceeding that limit.

Although Linux supports files larger than 2Gb, the code which deals
with such files has to use "off_t" instead of "long", so the code
would need to be updated to allow for this.

Actually, the GRASS code often performs offset calculations using
"int"s so, even on platforms where "long" is 64 bits, a lot of GRASS
would still have problems with files larger than 2Gb.

-- 
Glynn Clements <glynn.clements at virgin.net>




More information about the grass-user mailing list