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