<div dir="ltr"><div><div><div><div><div><br>On Thu, Jun 11, 2015 at 10:11 AM, Glynn Clements <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>> wrote:<br>><br>> > Anyway, I think that non-atomicity during copy (instead of move) when<br>> > requested (by GRASS_TMPDIR_MAPSET) is not much worse than anything else<br>> > what one must deal with when using GRASS on some advanced configuration.<br>> > For example, if you are writing to several vector maps with attributes in<br>> > parallel, it will take forever (with SQLite). However, if you use<br>> > PostgreSQL (or probably also DBF) as attribute backend, you get great<br>> > performance. Does this mean that you cannot write vectors with attributes<br>> > in parallel and perhaps also rasters to be on the safe side? No, it just<br>> > means that you need to configure your environment according to what you are<br>> > doing.<br>><br>> Database updates should be handled using transactions where available.<br>> I don't know whether this is already the case; I'm not that familiar<br>> with the vector or DBMI libraries.<br><br></div>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.<br><br></div>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).<br><br></div>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).<br><br></div>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?<br><br></div><div>Thanks for discussing this now,<br></div>Vaclav<br></div>