Typical usage pattern

  1. A user's workflow script (executed to advance the whole workflow) will call srmGet for files on tape and not currently on disk to stage them to the /cache disk for upcoming batch jobs (calling srmGet for a file already on disk does not cause the file to be re-read)
  2. When the necessary input files are on disk, the batch job is submitted by the workflow script; input files could be srmPin'd to ensure they will stay around until the job launches
  3. When the job starts, it copies the file from /cache to local disk (improves system performance)
  4. Output files from the batch job are written to /cache/myProject/some_path (copied from the compute node's local disk) if the file needs to be kept for a long time (longer than 6 months), or to /volatile/myProject/some_path if the file is temporary and will be consumed within weeks by another batch job.
  5. srmPut can be used for quicken the migration from disk to tape; optional -d deletes the disk copy when this is completed; this is especially useful if the file will not be needed soon for another batch job, and disk resources are tight
  6. srmUnpin the input files, freeing pin quota
  7. Remove the input files (safe since they are already on tape)