<div dir="ltr">Hi,<div><br></div><div>"scratch space" is generally considered ephemeral storage that only exists for the duration of the job (It's eligible for deletion in an epilog or next-job prolog) .</div><div><br></div><div>If you've got other fast storage in limited supply that can be used for data that can be staged, then by all means use it, but consider whether you want batch cpu cores tied up with the wall time of transferring the data. This could easily be done on a time-shared frontend login node from which the users could then submit (via script) jobs after the data was staged. Most of the transfer wallclock is in network wait, so don't waste dedicated cores for it.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Apr 3, 2021 at 4:13 PM Will Dennis <<a href="mailto:wdennis@nec-labs.com">wdennis@nec-labs.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="gmail-m_2817698644170583371WordSection1">
<p class="MsoNormal">What I mean by “scratch” space is indeed local persistent storage in our case; sorry if my use of “scratch space” is already a generally-known Slurm concept I don’t understand, or something like /tmp… That’s why my desired workflow is to
 “copy data locally / use data from copy / remove local copy” in separate steps.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(181,196,223);padding:3pt 0in 0in">
<p class="MsoNormal" style="margin-bottom:12pt"><b><span style="font-size:12pt;color:black">From:
</span></b><span style="font-size:12pt;color:black">slurm-users <<a href="mailto:slurm-users-bounces@lists.schedmd.com" target="_blank">slurm-users-bounces@lists.schedmd.com</a>> on behalf of Fulcomer, Samuel <<a href="mailto:samuel_fulcomer@brown.edu" target="_blank">samuel_fulcomer@brown.edu</a>><br>
<b>Date: </b>Saturday, April 3, 2021 at 4:00 PM<br>
<b>To: </b>Slurm User Community List <<a href="mailto:slurm-users@lists.schedmd.com" target="_blank">slurm-users@lists.schedmd.com</a>><br>
<b>Subject: </b>Re: [slurm-users] Staging data on the nodes one will be processing on via sbatch<u></u><u></u></span></p>
</div>
<div>
<div>
<p class="MsoNormal">[…]<u></u><u></u></p>
<p class="MsoNormal">The best current workflow is to stage data into fast local persistent storage, and then to schedule jobs, or schedule a job that does it synchronously (TImeLimit=Stage+Compute). The latter is pretty unsocial and wastes cycles.<u></u><u></u></p>
<p class="MsoNormal">[…]<u></u><u></u></p>
</div>
</div>
</div>
</div>

</blockquote></div>