[lustre-devel] lctl conf_param vs set_param -P
nathan.rutman at seagate.com
Mon Aug 17 20:37:35 PDT 2015
The goal of set_param -P (permanent, global) was to replace conf_param and
harmonize with set_param (local). (conf_param semantics were the beginning
of an aborted attempt to move away from /proc and toward a more rational
parameter space.) Unfortunately, most of the conf_param items were
"specials", that had to be re-implemented under set_param -P. Most of that
work was done years ago, but some things like "jobid" were not around then
-- and apparently were implemented using the older mechanism only.
So the right way forward to my mind is to deprecate conf_param, and fix the
broken things to work correctly with set_param -P.
*Nathan Rutman · Principal Systems ArchitectSeagate Technology** · *+1 503
877-9507* · *GMT-8
On Mon, Aug 17, 2015 at 11:06 AM, Christopher J. Morrone <morrone2 at llnl.gov>
> On 08/17/2015 09:10 AM, Artem Blagodarenko wrote:
>> >Can someone offer any insight on why the behavior appears to be
>> After "set_param -P" applied, lock for "params" file is canceled that
>> initiate this log is acquired and "executed" by targets and clients.
>> This requires some time.
> How much time? In human terms, this should happen in very little time on
> a vm with llmount.sh created filesystem, should it not?
> >Is it the intent of "set_param -P" that the specified changes only take
>> effect after components are restarted? And if so, why?
>> No, changes applied just after command executed, but some time
>> is required to cancel lock for params file.
> Perhaps that is what is intended to happen, but is that working on master?
> >How would a normal system administrator go about finding out what
>> settings are currently set permanently?
>> Seme settings as "set_param" sets can be set using "set_param -P".
>> Finally all command that stored using "set_param" executed using "lctl
>> set_param" upcall on targets.
> 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.
> >And what about sites that use an MGS per filesystem, rather than a
>> single MGS for the entire site? If one MGS says that the debug level
>> should be one value, and another says that the debug value should be
>> another value, is it entirely random which debug setting will appear on
>> any given node?
>> Good example there we could use reserved field. Do you think this can
>> solve the issue? If so, we could extend "set_param -P" now.
> I'm not so sure. I have a feeling that really we need to consider and
> classify all of the configurables.
> Another use case:
> 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.
> 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).
> >We might want to just remove the conf_param deprecation message
>> altogether. I think there is more than just a simple bug in the
>> "set_param -P" implementation.
>> I believe we need move to "set_param -P". Yes, this require some scripts
>> to be changed, but fixing this now we get method with this benefits
>> instead of conf_param:
> 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.
> Is there more design information out there to which you can point us?
> I belive we could solve found issues and move forward using "set_param -P"
>> I offered "set_param -P topic to last LAD, but unfortunately it was not
>> accepted. Lets' discuss this together. Moving conf_param discarding date
>> forward gives us some time for this.
> 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.
> lustre-devel mailing list
> lustre-devel at lists.lustre.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lustre-devel