[GRASS-dev] r65348: Mapset's tmp dir placement and broken element search

[Vaclav Petras]

On Wed, Jun 10, 2015 at 3:05 PM, Martin Landa <landa.martin at gmail.com>
wrote:
>
> 2015-06-10 17:41 GMT+02:00 Glynn Clements <glynn at gclements.plus.com>:
> >
> > Vaclav Petras wrote:
> >
> >> First, it allows unorthodox behavior of GRASS but this behavior is (or
at
> >> least should be) applied only when GRASS_TMPDIR_MAPSET is set to some
> >> specific value. I don't see much problem with it as long as the
> >> documentation properly discuss all the potential issues and the
default is
> >> the standard and safe way. This was discussed in [GRASS-dev] r65348
> >> (GRASS_TMPDIR_MAPSET).
> >
> > There is no justification for the current behaviour. The temporary
> > cell/fcell and null files should always be created in the mapset's
> > temporary directory.
>
> I am not sure why it must be so on (if files are not on the same
> filesystem, they can be copied), anyway I changed it in r65436.
> GRASS_TMPDIR_MAPSET is accepted only by vector library. Martin

I don't understand why it should be OK for vectors when it is not OK for
rasters.

Anyway, I think that non-atomicity during copy (instead of move) when
requested (by GRASS_TMPDIR_MAPSET) is not much worse than anything else
what one must deal with when using GRASS on some advanced configuration.
For example, if you are writing to several vector maps with attributes in
parallel, it will take forever (with SQLite). However, if you use
PostgreSQL (or probably also DBF) as attribute backend, you get great
performance. Does this mean that you cannot write vectors with attributes
in parallel and perhaps also rasters to be on the safe side? No, it just
means that you need to configure your environment according to what you are
doing.

To be precise, the parallel processing actually is not advanced
configuration. The advanced configuration is required to make it work. This
means that you need advanced configuration to make not so advanced thing
work. That's quite unfortunate but this only supports my point that you
need to understand how GRASS works with different configurations to get
good (or even acceptable) performance.

I would like to understand what are the possible issues and how much worse
are they, for example from what is default with SQLite as attribute backend
and parallel processing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20150610/86321815/attachment.html>