[GRASS-user] r.patch: GRASS-6.5svn
I have 9 raster elevation files that cover the entire state. When displayed simultaneously there are obvious mis-matches along the edges apparently because of different hight ranges. Yesterday I attempted to create a single DEM map for the entire state using r.patch. These are the steps I followed: MAPS=`g.mlist type=rast sep=, pat="dem*"` g.region rast=$MAPS r.patch in=$MAPS out=demOR Then I went off and did other things for a couple of hours. There was a warning about inability to write line 24nnn (I forget the exact line number), and when it was finished and I tried to display the whole new map, only the top portion (I'd estimate the top half) was present. Should I do this in slices (3 maps at a time), then patch the results into a single map? What might cause the results I saw? Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.patch: GRASS-6.5svn
On Fri, 15 Jan 2010, Rich Shepard wrote: I need ideas on how to find the source of the problem. What might cause such an error? Does anyone know why r.patch and/or r.series would generate an error about not being able to write a row when maps are concatenated? It seems to me that if the data are good (which they seem to be), and I can combine the two suspect maps (of the 9 total) with surrounding ones one at a time until a threshold is reached, it must be something with the two modules that's failing. I'd really like to fix this so I can get the DEM for the entire state before I try for other states. Thanks, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.patch: GRASS-6.5svn
Rich Shepard wrote:
> > I need ideas on how to find the source of the problem. What might cause
> > such an error?
>
>Does anyone know why r.patch and/or r.series would generate an error about
> not being able to write a row when maps are concatenated? It seems to me
> that if the data are good (which they seem to be), and I can combine the two
> suspect maps (of the 9 total) with surrounding ones one at a time until a
> threshold is reached, it must be something with the two modules that's
> failing.
The error "map [%s] - unable to write row %d" doesn't originate in a
module, it originates in the library, and invariably indicates that
write() failed.
[If you're getting a different error, please post the *exact* error
message, not a paraphrase.]
This can be caused by many things, including (but not limited to):
* Exceeding the 2GiB limit on a build without LFS.
* Exceeding the 4GiB limit of a FAT filesystem.
* Exceeding "ulimit -f".
* Exceeding quota.
* Disk full.
* Hardware error
If you built GRASS from source, apply the attached patch with:
patch -p0 < write_errno.patch
from the top-level directory of the GRASS source tree, then
re-compile.
This will cause the underlying OS error to be included in the error
message.
The issue isn't limited to a specific module. I would expect to see
the same issue with almost any raster command run with the same
region, e.g.:
r.mapcalc 'test = rand(-1.0,1.0)'
Note: I wouldn't expect to see the issue with a trivial test case such
as:
r.mapcalc 'test = 0'
because such a map will compress very well, and it's the size of the
compressed data which matters.
--
Glynn Clements
Index: lib/gis/put_row.c
===
--- lib/gis/put_row.c (revision 40542)
+++ lib/gis/put_row.c (working copy)
@@ -122,6 +122,7 @@
**/
#include
+#include
#include
#include
@@ -307,7 +308,8 @@
if (fcb->io_error)
return;
-G_warning(_("map [%s] - unable to write row %d"), fcb->name, row);
+G_warning(_("map [%s] - unable to write row %d (%s)"), fcb->name, row,
+ strerror(errno));
fcb->io_error = 1;
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.patch: GRASS-6.5svn
On Thu, 21 Jan 2010, Glynn Clements wrote: The error "map [%s] - unable to write row %d" doesn't originate in a module, it originates in the library, and invariably indicates that write() failed. [If you're getting a different error, please post the *exact* error message, not a paraphrase.] Hi Glynn, I killed the r.patch process 66% through because the warning was issued and in previous attempts this stopped the map being completely displayed: GRASS 6.5.svn (Oregon):/usr4/grassbase > MAPS=`g.mlist type=rast sep=, pat="demCEN,demE,demN,demNE,demNW,demS,demSE,demSW,demW"` GRASS 6.5.svn (Oregon):/usr4/grassbase > g.region rast=$MAPS GRASS 6.5.svn (Oregon):/usr4/grassbase > r.patch in=$MAPS out=demOR --o WARNING: map [demOR] - unable to write row 24578 This can be caused by many things, including (but not limited to): * Exceeding the 2GiB limit on a build without LFS. Here are the configure options I use with -6.4 and -6.5: --with-postgres \ --with-sqlite \ --with-cairo \ --with-freetype \ --with-cxx \ --with-geos=usr/bin/geos-config \ --with-gdal=/usr/bin/gdal-config \ --with-python=/usr/bin/python-config \ --with-wxwidgets=/usr/bin/wx-config \ --with-includes=/usr/include/ \ --with-libs=/usr/lib/ \ --enable-largefile * Exceeding the 4GiB limit of a FAT filesystem. No FAT on linux. * Exceeding "ulimit -f". [rshep...@salmo ~]$ ulimit -f unlimited * Exceeding quota. Quotas not enabled; or at default values. * Disk full. [rshep...@salmo ~]$ df -h /usr4 FilesystemSize Used Avail Use% Mounted on /dev/hdc3 38G 24G 15G 63% /usr4 * Hardware error Perhaps, but no problems elsewhere. If you built GRASS from source, apply the attached patch with: patch -p0 < write_errno.patch from the top-level directory of the GRASS source tree, then re-compile. This will cause the underlying OS error to be included in the error message. Here are the results: GRASS 6.5.svn (Oregon):/usr4/grassbase > MAPS=.mlist type=rast sep=, pat="demCEN,demE,demN,demNE,demNW,demS,demSE,demSW,demW" GRASS 6.5.svn (Oregon):/usr4/grassbase > g.region rast=$MAPS GRASS 6.5.svn (Oregon):/usr4/grassbase > r.patch in=$MAPS out=demOR --o WARNING: map [demOR] - unable to write row 24578 (No such file or directory) 100% Creating support files for raster map and GRASS 6.5.svn (Oregon):/usr4/grassbase > g.list rast -- raster files available in mapset : demCEN demE demN demNE demNW demOR demS demSE demSW demW so the file is present. But, ... GRASS 6.5.svn (Oregon):/usr4/grassbase > d.rast demOR WARNING: Error reading compressed map , row 0 Segmentation fault Here's what r.info has to tell about the map: GRASS 6.5.svn (Oregon):/usr4/grassbase > r.info demOR ++ | Layer:demOR Date: Thu Jan 21 18:36:57 2010| | Mapset: PERMANENT Login of Creator: rshepard| | Location: Oregon | | DataBase: /usr4/grassbase | | Title:DEM 10m Central Oregon ( demOR ) | | Timestamp: none| || || | Type of Map: raster Number of Categories: 11231 | | Data Type:CELL | | Rows: 53388 | | Columns: 71949 | | Total Cells: 3841213212 | |Projection: Lambert Conformal Conic | |N: 1737497.65432757S: -13512.48800518 Res: 32.7978224 | |E: 2502682.81668463W: 142938.14294121 Res: 32.79746312| | Range of data:min = 0 max = 11231 | Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.patch: GRASS-6.5svn
Rich Shepard wrote:
> GRASS 6.5.svn (Oregon):/usr4/grassbase > r.patch in=$MAPS out=demOR --o
> WARNING: map [demOR] - unable to write row 24578 (No such file or
> directory)
"No such file or directory" is ENOENT, which isn't among the errors
which write() can return. That suggests that write() is succeeding,
but returning a short count (i.e. it wrote some data, not all of it).
I suspect that a subsequent write() will result in an actual error and
indicate the cause, but write_error() only reports the first error (so
that you don't get thousands of them).
Can you revert the previous patch with:
patch -R -p0 < write_errno.patch
then apply the attached patch with:
patch -R -p0 < write_errors.patch
and re-compile.
That should cause it to print more than one error.
Also, can you provide the output from:
ls -l /usr4/grassbase/Oregon/PERMANENT/cell/demOR
BTW, do you get similar errors with other commands using the same
region, e.g.:
r.mapcalc 'test = rand()'
?
--
Glynn Clements
Index: lib/gis/put_row.c
===
--- lib/gis/put_row.c (revision 40542)
+++ lib/gis/put_row.c (working copy)
@@ -122,6 +122,7 @@
**/
#include
+#include
#include
#include
@@ -304,12 +305,13 @@
{
struct fileinfo *fcb = &G__.fileinfo[fd];
-if (fcb->io_error)
+if (fcb->io_error > 2)
return;
-G_warning(_("map [%s] - unable to write row %d"), fcb->name, row);
+G_warning(_("map [%s] - unable to write row %d (%s)"), fcb->name, row,
+ strerror(errno));
-fcb->io_error = 1;
+fcb->io_error++;
return;
}
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.patch: GRASS-6.5svn
On Fri, 22 Jan 2010, Glynn Clements wrote: Can you revert the previous patch with: patch -R -p0 < write_errno.patch then apply the attached patch with: patch -R -p0 < write_errors.patch and re-compile. That should cause it to print more than one error. GRASS 6.5.svn (Oregon):/usr4/grassbase > r.patch in=$MAPS out=demOR --o WARNING: map [demOR] - unable to write row 24578 (No such file or directory) WARNING: map [demOR] - unable to write row 24578 (File too large) WARNING: map [demOR] - unable to write row 24578 (File too large) 100% Creating support files for raster map I've not before encountered 'file too large' ... Also, can you provide the output from: ls -l /usr4/grassbase/Oregon/PERMANENT/cell/demOR But this explains it: 2147483647 Jan 22 07:39 /usr4/grassbase/Oregon/PERMANENT/cell/demOR That's a 2G file size for 10m resolution DEM of the entire state. Wow! What's the best strategy for decreasing file size? Do I not make a state-wide DEM but make 2 or three instead? Should I keep the 9 separate maps and concatenate as necessary for specific projects? This has been a _very_ useful lesson. BTW, do you get similar errors with other commands using the same region, e.g.: r.mapcalc 'test = rand()' GRASS 6.5.svn (Oregon):/usr4/grassbase > r.mapcalc 'test = rand()' Too few arguments (1) to function rand() Parse error Thanks, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.patch: GRASS-6.5svn
Rich Shepard wrote: > > Can you revert the previous patch with: > > patch -R -p0 < write_errno.patch > > then apply the attached patch with: > > patch -R -p0 < write_errors.patch > > and re-compile. > > That should cause it to print more than one error. > > > GRASS 6.5.svn (Oregon):/usr4/grassbase > r.patch in=$MAPS out=demOR --o > WARNING: map [demOR] - unable to write row 24578 (No such file or directory) > WARNING: map [demOR] - unable to write row 24578 (File too large) > WARNING: map [demOR] - unable to write row 24578 (File too large) > 100% > Creating support files for raster map > >I've not before encountered 'file too large' ... The code is EFBIG. EFBIG An attempt was made to write a file that exceeds the implementa- tion-defined maximum file size or the process's file size limit, or to write at a position past the maximum allowed offset. That rules out disk full (which fails with ENOSPC). > > Also, can you provide the output from: > > ls -l /usr4/grassbase/Oregon/PERMANENT/cell/demOR > >But this explains it: > > 2147483647 Jan 22 07:39 /usr4/grassbase/Oregon/PERMANENT/cell/demOR Yep, that's the 2GiB limit. >That's a 2G file size for 10m resolution DEM of the entire state. Wow! > >What's the best strategy for decreasing file size? Do I not make a > state-wide DEM but make 2 or three instead? Should I keep the 9 separate > maps and concatenate as necessary for specific projects? Actually, I want to know why the 2GiB limit is there. 1. Can you confirm that include/Make/Platform.make contains: #Large File Support (LFS) USE_LARGEFILES = 1 2. Can you re-compile lib/gis and check that the compilation commands include the flag -D_FILE_OFFSET_BITS=64. [r.patch shouldn't need any particular compilation flags, as the file in question is created and written by lib/gis.] 3. Can you provide the files produced by the following commands (run from within a GRASS session): ldd $GIBASE/bin/r.patch > ldd.txt nm -D $GISBASE/lib/libgrass_gis.so > nm.txt >This has been a _very_ useful lesson. > > > BTW, do you get similar errors with other commands using the same > > region, e.g.: > > r.mapcalc 'test = rand()' > > GRASS 6.5.svn (Oregon):/usr4/grassbase > r.mapcalc 'test = rand()' > Too few arguments (1) to function rand() > Parse error Oops; that should have been rand(0,). But I think I already know how that would have turned out. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.patch: GRASS-6.5svn
On Sat, 23 Jan 2010, Glynn Clements wrote: Actually, I want to know why the 2GiB limit is there. Glynn, Me, too! 1. Can you confirm that include/Make/Platform.make contains: #Large File Support (LFS) USE_LARGEFILES = 1 Yes, those two lines are present. 2. Can you re-compile lib/gis and check that the compilation commands include the flag -D_FILE_OFFSET_BITS=64. lib/gis/Makefile contains: #compile if LFS Large File Support present: ifneq ($(USE_LARGEFILES),) EXTRA_CFLAGS = -D_FILE_OFFSET_BITS=64 endif [r.patch shouldn't need any particular compilation flags, as the file in question is created and written by lib/gis.] 3. Can you provide the files produced by the following commands (run from within a GRASS session): ldd $GIBASE/bin/r.patch > ldd.txt We actually want the environmental variable to be $GISBASE. ldd.txt: linux-gate.so.1 => (0xe000) /lib/libsafe.so.2 (0xb7f77000) libgrass_gis.so => /usr/local/grass-6.5.svn/lib/libgrass_gis.so (0xb7f2b000) libgrass_datetime.so => /usr/local/grass-6.5.svn/lib/libgrass_datetime.so (0xb7f23000) libz.so.1 => /usr/lib/libz.so.1 (0xb7eee000) libm.so.6 => /lib/libm.so.6 (0xb7ec8000) libc.so.6 => /lib/libc.so.6 (0xb7d7c000) libdl.so.2 => /lib/libdl.so.2 (0xb7d78000) /lib/ld-linux.so.2 (0xb7f7e000) nm -D $GISBASE/lib/libgrass_gis.so > nm.txt That file's 905 lines long so I'll attach it to the message rather than inserting it here. Thanks, Rich0003c3b0 T G_3dview_warning 0004b540 B G__ d5b0 T G__allocate_null_bits d4f0 T G__calloc ef80 T G__check_for_auto_masking 0001b8b0 T G__check_format 00027c50 T G__check_fp_type 00020d50 T G__check_gisinit 00026b60 T G__check_null_bit 00012710 T G__color_free_fp_lookup 00012760 T G__color_free_lookup 000127c0 T G__color_free_rules 00012810 T G__color_reset 00026ac0 T G__convert_01_flags 00026a30 T G__convert_flags_01 00019690 T G__create_alt_env 00025e40 T G__create_alt_search_path 0003e850 T G__create_window_mapping 00019930 T G__env_name 0001a8a0 T G__file_name 0001a6f0 T G__file_name_misc 000192e0 T G__get_gisrc_file 00020630 T G__get_window 00019a90 T G__getenv 000199e0 T G__getenv2 00020eb0 T G__gisinit 00022010 T G__home 000269b0 T G__init_null_bits 0003e7a0 T G__init_window 00012fa0 T G__insert_color_into_lookup 00013410 T G__interpolate_color_rule 000249b0 T G__location_path 00013510 T G__lookup_colors 00024c60 T G__ls 00024e40 T G__machine_name 000252d0 T G__make_location 000258d0 T G__make_mapset 00025ca0 T G__make_mapset_element 00025df0 T G__make_mapset_element_misc d4a0 T G__malloc 00025aa0 T G__mapset 00026230 T G__mapset_name 00025c10 T G__mapset_permissions 00025b80 T G__mapset_permissions2 00026370 T G__mask_info 000268a0 T G__name_in_mapset 00026750 T G__name_is_fully_qualified 00020e40 T G__no_gisinit d580 T G__null_bitstream_size 00028d80 T G__open_cell_old 00031b10 T G__open_null_write 000140b0 T G__organize_colors 00031360 T G__projection_name 00031270 T G__projection_units 00032210 T G__put_null_value_row 00033080 T G__put_window 000341a0 T G__quant_export 000337c0 T G__quant_get_rule_for_d_raster_val 000346f0 T G__quant_import 00033ae0 T G__quant_organize_fp_lookup 000224e0 T G__random_d_initialize_0 000223f0 T G__random_f_initialize_0 000361e0 T G__raster_misc_read_line 00036100 T G__raster_misc_write_line 000372d0 T G__read_Cell_head 000364c0 T G__read_Cell_head_array 00010800 T G__read_cats 000192c0 T G__read_env 0001b6e0 T G__read_row_ptrs 0003b480 T G__read_timestamp d430 T G__realloc 00028100 T G__reallocate_mask_buf 00028190 T G__reallocate_null_buf 00028070 T G__reallocate_temp_buf 00028210 T G__reallocate_work_buf 00035600 T G__remove_fp_range 00035090 T G__row_update_range 00026be0 T G__set_flags_from_01_random 00019350 T G__set_gisrc_file 00027030 T G__set_null_value 000199c0 T G__setenv 000199a0 T G__setenv2 00019300 T G__switch_env 00025e80 T G__switch_search_path 0003ad80 T G__temp_element 0003adf0 T G__tempfile 000312c0 T G__unit_name 0003ead0 T G__write_Cell_head 0003ec90 T G__write_Cell_head3 fed0 T G__write_cats 00016ab0 T G__write_colors 00031d00 T G__write_data 00031c90 T G__write_data_compressed 00019c60 T G__write_env 00011700 T G__write_fp_format 00031a70 T G__write_null_bits 0001b5f0 T G__write_row_ptrs 0003b2e0 T G__write_timestamp 00017150 T G_abs_log_colors 000158a0 T G_add_c_raster_color_rule 00015800 T G_add_color_rule 00015940 T G_add_d_raster_color_rule 000158f0 T G_add_f_raster_color_rule 00021430 T G_add_histogram 00025fd0 T G_add_mapset_to_search_path 000155d0 T G_add_modular_c_raster_color_rule 00015520 T G_add_modular_color_rule 00015770 T G_add_modular_d_raster_color_rule 000156e0 T G_add_modular_f_raster_color_rule 00015620 T G_add_modular_raster_color_rule 00015850 T G_add_raster_color_rule ce40 T G_adjust_Cell_head c940 T G_adjust_Cell_head3 0003e570 T G_adjust_east_longitude 0
Re: [GRASS-user] r.patch: GRASS-6.5svn
Rich Shepard wrote: > > 2. Can you re-compile lib/gis and check that the compilation commands > > include the flag -D_FILE_OFFSET_BITS=64. > >lib/gis/Makefile contains: > > #compile if LFS Large File Support present: > ifneq ($(USE_LARGEFILES),) > EXTRA_CFLAGS = -D_FILE_OFFSET_BITS=64 > endif Right. But if you do e.g.: touch lib/gis/opencell.c make -C lib/gis does the -D_FILE_OFFSET_BITS=64 switch appear in the output? > > [r.patch shouldn't need any particular compilation flags, as the file > > in question is created and written by lib/gis.] > > > > 3. Can you provide the files produced by the following commands (run > > from within a GRASS session): > > nm -D $GISBASE/lib/libgrass_gis.so > nm.txt > >That file's 905 lines long so I'll attach it to the message rather than > inserting it here. This isn't good: > U __lxstat > U __xstat > U creat > U fopen > U freopen > U lseek > U lseek64 > U open > U open64 > U readdir This implies that most of the library was built without LFS. If I run the above command here, the corresponding entries are: U __lxstat64 U __xstat64 U creat64 U fopen64 U freopen64 U lseek64 U open64 U readdir64 One possibility is that GRASS was initially built without LFS, then configure was re-run with --enable-largefile and GRASS was built without first performing "make clean". This would result in most of the files not be re-compiled. I suggest removing both the installed version of GRASS and the source tree, then compiling from scratch (run make with e.g. "make &> build.log" to capture all of the output). After compiling, check the output from "nm ... libgrass_gis.so" and ensure that all of the above symbols have the "64" suffix. If they don't, send me the complete make output off-list (compress it first, as it's likely to be around 3MB uncompressed vs 120KB compressed). -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.patch: GRASS-6.5svn
On Sun, 24 Jan 2010, Glynn Clements wrote: Right. But if you do e.g.: touch lib/gis/opencell.c make -C lib/gis does the -D_FILE_OFFSET_BITS=64 switch appear in the output? Glynn, It appears so: gcc -I/usr4/grass65/dist.i686-pc-linux-gnu/include -I/usr/include/ -g -O2 -I/usr/include/ -fPIC -DPACKAGE=\""grasslibs"\" -D_FILE_OFFSET_BITS=64 -DGDAL_LINK=1 -DGDAL_DYNAMIC=1 -DPACKAGE=\""grasslibs"\" -I/usr/include -I/usr/include -I/usr4/grass65/dist.i686-pc-linux-gnu/include -o OBJ.i686-pc-linux-gnu/opencell.o -c opencell.c One possibility is that GRASS was initially built without LFS, then configure was re-run with --enable-largefile and GRASS was built without first performing "make clean". This would result in most of the files not be re-compiled. I suggest removing both the installed version of GRASS and the source tree, then compiling from scratch (run make with e.g. "make &> build.log" to capture all of the output). OK. After compiling, check the output from "nm ... libgrass_gis.so" and ensure that all of the above symbols have the "64" suffix. If they don't, send me the complete make output off-list (compress it first, as it's likely to be around 3MB uncompressed vs 120KB compressed). More after I do this. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.patch: GRASS-6.5svn
On Sun, 24 Jan 2010, Glynn Clements wrote: One possibility is that GRASS was initially built without LFS, then configure was re-run with --enable-largefile and GRASS was built without first performing "make clean". This would result in most of the files not be re-compiled. Glynn, This must have been the case. I ran "make dist-clean", then "configure & make & make install". When I ran r.patch on the 9 DEM maps it successfully produced a 4.6G DEM file of the entire state. Normally, when I rebuild from source I run "make clean" or "make dist-clean" first. Why I did not do so this time I don't know. Brain fart, perhaps. Thanks for guiding me to the proper solution, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.patch: GRASS-6.5svn -- UPDATE
On Fri, 15 Jan 2010, Rich Shepard wrote: There was a warning about inability to write line 24nnn (I forget the exact line number), and when it was finished and I tried to display the whole new map, only the top portion (I'd estimate the top half) was present. I need ideas on how to find the source of the problem. Made 3 horizontal maps, north, central, south from the 9 maps. No problems making or displaying them. However, ... When I tried to patch the three together the error displayed 'unable to write row 24580.' I removed that map attempt and tried to patch the north and central maps together; this produced the error, 'unable to write row 24581.' What might cause such an error? This is in the central band which displays without comment by itself. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.patch: GRASS-6.5svn -- UPDATE
Rich Shepard wrote: > > There was a warning about inability to write line 24nnn (I forget the > > exact line number), and when it was finished and I tried to display the > > whole new map, only the top portion (I'd estimate the top half) was present. > >I need ideas on how to find the source of the problem. > >Made 3 horizontal maps, north, central, south from the 9 maps. No problems > making or displaying them. However, ... > >When I tried to patch the three together the error displayed 'unable to > write row 24580.' I removed that map attempt and tried to patch the north > and central maps together; this produced the error, 'unable to write row > 24581.' > >What might cause such an error? This is in the central band which displays > without comment by itself. The most likely reasons are: 1. Your version of GRASS was built without LFS (large file support), and the cell/fcell file reached the 2GiB limit. 2. The disk is full or you exceeded your quota. If you're building GRASS yourself, be sure to use the --enable-largefile option when running configure. -- Glynn Clements ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.patch: GRASS-6.5svn -- UPDATE
On Fri, 15 Jan 2010, Glynn Clements wrote: The most likely reasons are: 1. Your version of GRASS was built without LFS (large file support), and the cell/fcell file reached the 2GiB limit. Glynn, Nope. LFS was enabled. 2. The disk is full or you exceeded your quota. Nope. There are 14G available on that partition. If you're building GRASS yourself, be sure to use the enable-largefile --option when running configure. See 1 above. I've been experimenting today and I think it's an error in one of the 9 individual maps. Probably one of those in the middle. I get the same error when I try to patch the top third or bottom third with the middle third. Now I'll patch them together one map at a time until I identify the culprit, then I'll re-import that puppy. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
