[ET Trac] [Einstein Toolkit] #860: Don't rmtree(scratchdir)

[Einstein Toolkit]

#860: Don't rmtree(scratchdir)
----------------------------+-----------------------------------------------
  Reporter:  barry.wardell  |       Owner:  eschnett
      Type:  defect         |      Status:  new     
  Priority:  blocker        |   Milestone:          
 Component:  SimFactory     |     Version:          
Resolution:                 |    Keywords:          
----------------------------+-----------------------------------------------

Comment (by barry.wardell):

 Replying to [comment:1 eschnett]:
 > In most cases, the scratch directory contains e.g. the job id, as in
 > {{{
 > /scratch/scratchdirs/@USER@/scratch/@JOB_ID@
 > }}}
 > to guarantee that it is unique.
 >
 > One solution could be to check whether the scratch directory is empty
 before a job starts, or to even ensure that it does not exist. If it
 exists this would be a fatal error, pointing to a significant
 inconsistency in the MDB or the system setup.

 I think this is a good idea (checking that the directory doesn't exist
 before the job starts).

 It's OK to have a per-simulation directory which is created and removed by
 SimFactory. The problem is the current implementation which is potentially
 unsafe. The logic ensuring that the scratch directory is unique to a
 simulation which is currently implemented in each mdb entry should be
 moved out of the MDB and into the code. This could be achieved as you
 suggest:

 > Another option would be to deprecate scratchdir (since at least one
 person misunderstood its meaning), and introduce scratchbasedir instead.
 The scratchbasedir is supposed to exist, and the scratchdir is created as
 a subdirectory (that must not yet exist). This subdirectory will then be
 deleted again when the restart finishes.
 >
 > If scratchbasedir is not set, a subdirectory of the simulation directory
 would be used. Setting scratchbasedir will allow using a faster file
 system if one is available.


 > In the mean time: Please tell me which machine this is, so that we can
 correct its MDB.

 I have already corrected the entry for the relevant machine (tesla). In
 fact, it wasn't really the mdb at fault, but my own defs.local.ini where I
 had set basedir = /scratch so that my simulation data would be output to a
 nice fast filesystem. To allow me to still do this, I changed the MDB
 entry to be scratchdir = scratchdir.

-- 
Ticket URL: <https://trac.einsteintoolkit.org/ticket/860#comment:2>
Einstein Toolkit <http://einsteintoolkit.org>
The Einstein Toolkit