On Fri, Jul 11, 2008 at 4:57 PM, Glen Beane &lt;<a href="mailto:glen.beane@gmail.com">glen.beane@gmail.com</a>&gt; wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c"><br><br><div class="gmail_quote">On Fri, Jul 11, 2008 at 4:43 PM, Garrick Staples &lt;<a href="mailto:garrick@usc.edu" target="_blank">garrick@usc.edu</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

On Fri, Jul 11, 2008 at 04:28:43PM -0400, Glen Beane alleged:<br>
<div><div></div><div>&gt; I&#39;ve been working on some changes in trunk that transfer the .OU and .ER<br>
&gt; spool files from pbs_mom back to pbs_server. This is one of the steps we<br>
&gt; need to take so that a job in the COMPLETE state can be restarted from a<br>
&gt; checkpoint file. &nbsp;(the files are only returned to the server if<br>
&gt; keep_completed is positive and the job has a checkpoint file)<br>
&gt;<br>
&gt; There are problems when the spool file is shared between pbs_server and the<br>
&gt; mother superior pbs_mom. What happens is that when the files are &quot;returned&quot;<br>
&gt; pbs_server takes ownership of the .ER and .OU files in the spool dir and<br>
&gt; when pbs_mom forks to the user to copy the files back to the user home<br>
&gt; directory they are unable to do so because of a permission denied error. &nbsp;I<br>
&gt; feel that the cleanest solution is to just separate the pbs_server and<br>
&gt; pbs_mom spool directories. &nbsp;In my current working copy of trunk I have<br>
&gt; changed pbs_server to use server_home/server_spool instead of<br>
&gt; server_home/spool. &nbsp;pbs_mom continues to use server_home/spool. &nbsp;This solves<br>
&gt; my problems because when the spool files are returned to pbs_server pbs_mom<br>
&gt; retains its copy it its own spool directory. It is then free to fork to the<br>
&gt; user to copy the files and then delete them.<br>
&gt;<br>
&gt; Are there any objections to this change in trunk? (the change will be<br>
&gt; introduced with the release of TORQUE 2.4.0)<br>
<br>
</div></div>So we&#39;re doing a useless copy from server_home/spool to<br>
server_home/server_spool? &nbsp; At my site, these files are often a significant<br>
percentage of the filesystem. &nbsp;If a file is more than 50% of the total<br>
filesystem, then this is going to fail.<br>
<br>
Why not just have the server check if it already has the file and not issue a<br>
copy request?</blockquote></div><br></div></div>you probably don&#39;t run pbs_mom and pbs_server on the same host do you?&nbsp; ;)&nbsp; I think 99% of the time the copy from pbs_mom to pbs_server is going to be required.&nbsp; <br><br>
As for this special case, yes if they can share the same spool directory then it would be good so we don&#39;t have to do the copy, however the problem is letting pbs_mom know that pbs_server is using the same spool directory.&nbsp; pbs_mom assumes it owns the file and will delete it when it is done. If pbs_server takes ownership of the file then it either has to make it world readable (then anyone can snoop on the contents of the .OU and .ER files while the job is in the COMPLETE state) or pbs_mom can not copy the file back to the user directory (permission denied). If it does not take ownership of the file then there needs to be some way to keep pbs_mom from deleting the file when it is done with it.&nbsp; <br>

<br>I guess we could have a job attribute do_not_delete_spool_files that pbs_server could set.&nbsp; What do you think? Then I would skip the copy but I would still have to make pbs_server know it owns the files so it cleans them up after the keep_compled time expires.<br>

<br><br>This brings up another issue.&nbsp; If there are a lot of checkpointed jobs in the COMPLETE state then that means there can be a huge amount of data that has to be stored by pbs_server.</blockquote><div><br><br>So you&#39;ve helped convince me that the easy way out is a bad idea (is it ever?).&nbsp; Thanks a lot Garrick. ;)<br>
&nbsp;</div></div>