<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">How much time?  In human terms, this should happen in very little time on a vm with llmount.sh created filesystem, should it not?</span></blockquote><div><br></div><div>If it uses the same timeout as the other config locks, it will take between 5-10 seconds (5 + 0 to 5 random seconds). It's all done in the mgc_requeue_thread function.</div><div><br></div><div>- Kit  </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 17, 2015 at 2:06 PM, Christopher J. Morrone <span dir="ltr"><<a href="mailto:morrone2@llnl.gov" target="_blank">morrone2@llnl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 08/17/2015 09:10 AM, Artem Blagodarenko wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hello,<br>
<br>
 >Can someone offer any insight on why the behavior appears to be<br>
</blockquote></span>
[cut]<span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
After "set_param -P" applied, lock for "params" file is canceled that<br>
initiate this log is acquired and "executed" by targets and clients.<br>
This requires some time.<br>
</blockquote>
<br></span>
How much time?  In human terms, this should happen in very little time on a vm with llmount.sh created filesystem, should it not?<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 >Is it the intent of "set_param -P" that the specified changes only take<br>
effect after components are restarted?  And if so, why?<br>
<br>
No, changes applied just after command executed, but some time<br>
is required to cancel lock for params file.<br>
</blockquote>
<br></span>
Perhaps that is what is intended to happen, but is that working on master?<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 >How would a normal system administrator go about finding out what<br>
settings are currently set permanently?<br>
<br>
Seme settings as "set_param" sets can be set using "set_param -P".<br>
Finally all command that stored using "set_param" executed using "lctl<br>
set_param" upcall on targets.<br>
</blockquote>
<br></span>
That was not the question.  I asked how a system administrator can get a listing of the parameters that have been permanently set.  It would appear that the only current method is to mount the underlying filesystem, locate the log file, and use llog_reader on it.  That is a software developer's interface, not an adequate interface for system administrators.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 >And what about sites that use an MGS per filesystem, rather than a<br>
single MGS for the entire site?  If one MGS says that the debug level<br>
should be one value, and another says that the debug value should be<br>
another value, is it entirely random which debug setting will appear on<br>
any given node?<br>
<br>
Good example there we could use reserved field. Do you think this can<br>
solve the issue? If so, we could extend "set_param -P" now.<br>
</blockquote>
<br></span>
I'm not so sure.  I have a feeling that really we need to consider and classify all of the configurables.<br>
<br>
Another use case:<br>
<br>
In WAN usage, two completely different organizations (two different universities, for instance) with separate security and administration policies may control different parts of the filesystem.  One organization runs the servers and some clients of its own.  A second organization runs clients that mount the first organization's servers over the internet.<br>
<br>
The second organization probably doesn't want the first organization to be setting _most_ of the settings that are available under lnet and lustre /proc trees.  But there are certainly some that are specific to the running of that filesystem that might be reasonable to pass to parts of the client that pertain to only that mount (keep in mind that the same client node may be mounting both local and remote lustre filesystems).<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 >We might want to just remove the conf_param deprecation message<br>
altogether.  I think there is more than just a simple bug in the<br>
"set_param -P" implementation.<br>
<br>
I believe we need move to "set_param -P". Yes, this require some scripts<br>
to be changed, but fixing this now we get method with this benefits<br>
instead of conf_param:<br>
</blockquote>
<br></span>
I would agree if there was no change other than than interface, but this also changes underlying semantics.  That concerns me since there seems to be little information about the design and not much in the way of vetting said design.<br>
<br>
Is there more design information out there to which you can point us?<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I belive we could solve found issues and move forward using "set_param -P"<br>
I offered "set_param -P topic to last LAD, but unfortunately it was not<br>
accepted. Lets' discuss this together. Moving conf_param discarding date<br>
forward gives us some time for this.<br>
</blockquote>
<br></span>
This mailing list reaches a greater number of Lustre developers than LAD or LUG can ever reach (travel is expensive, email is cheap).  This list is very good place to work through design and implementation issues.<br>
<br>
Chris<span class=""><br>
<br>
_______________________________________________<br>
lustre-devel mailing list<br>
<a href="mailto:lustre-devel@lists.lustre.org" target="_blank">lustre-devel@lists.lustre.org</a><br>
</span><a href="http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org" rel="noreferrer" target="_blank">http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org</a><br>
</blockquote></div><br></div>