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

[Vaclav Petras]

On Thu, Jun 11, 2015 at 10:11 AM, Glynn Clements <glynn at gclements.plus.com>
wrote:
>
> > 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.
>
> Database updates should be handled using transactions where available.
> I don't know whether this is already the case; I'm not that familiar
> with the vector or DBMI libraries.

I should have said that I mean parallel calls of modules from Python/Bash
script, e.g. r.to.vect or v.what.rast. I think transactions are not
applicable in this case (can a transaction work across processes?). In case
of one process, I'm not sure how transactions relate to parallel processing
but they should be used as much as possible, that's for sure.

Anyway, my point is that parallel calls to r.to.vect are terribly slow with
default configuration and one must know that the solution is to change the
attribute table backend to Postgres (or perhaps DBF where there is one
database file per vector map AFAIK).

Similarly, in case of setting changing the Mapset's tmp dir to something
one some other file systems for performance reasons, one must be aware of
the raster and vector maps being in inconsistent state for some time which
if fine as long as I'm not reading them. Thus, I don't see an issue with
the alternative location of Mapset's tmp directory (GRASS_TMPDIR_MAPSET).

I wonder if I can get the behavior even without GRASS_TMPDIR_MAPSET. Can I
create .tmp in my Mapset as link to directory on some other file system? Or
can I mount there some other directory?

Thanks for discussing this now,
Vaclav
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20150611/24eb9b86/attachment.html>