[LU-2629] set_param and conf_param have different syntaxes

• Status: Resolved
• Project: Lustre
• Type: Improvement
• Priority: Minor
• Reporter: Nathan Rutman
• Assignee: WC Triage
• Resolution: Duplicate
• Bugzilla ID: 17,471

Description

Replace the whole conf_param "direct" proc access with a simple upcall-type mechanism from the MGC.

1. on MGS: lctl conf_param random-proc-string=random-value-string
2. gets added to a single special param log, loaded after the individual config logs
3. this param log (and updates) get pulled by all the clients and servers
4. MGC executes via upcall-type mechanism to userspace (i.e. an ioctl) a local lctl set_param string=value

Benefits:

• identical conf_param / set_param
• "permanent" wildcarding in strings
• no unimplemented conf_param paths (e.g. ptlrpc services)
• simpler implementation

Interoperability:

• mgs_setparam and mgs_write_log_param must be updated to deal with the new param syntax. All exceptions and special cases should be removed as much as possible (verify that all settings can be made via /proc instead. Ideally we can move "active" and "failnids" into that category also??). We should probably keep the old version of these, and create mgs_setparam2 and ...log_param2. Add this to the old ones: /* compat: remove after Lustre 2.8 */
• Clients only use ll_send_mgc_param for setting default striping - we need to make sure this works with the new mgs_setparam2 mechanism.
• New clients must be able to process both old and new parameter syntaxes; add a new LCFG_PARAM2 to indicate the new syntax. Code for the old mechanism should have comments added: /* compat: remove after Lustre 2.8 */
  • Old clients will not be able to parse the new syntax. Clients should therefore be updated before setting new params. Old clients should safely report errors if they see a new-format param in the config llog.
  • New clients will need to be able to parse the old syntax for existing config log files.
• class_process_config for LCFG_PARAM2 should just set the param via the upcall with no further processing. Individual obd processing of LCFG_PARAM2 should not be necessary (but please make sure the current individual obd's currently all use class_process_proc_param for all param).
• mkfs.lustre parameters should use the new mechanism.
• Conf_param -d should search for matching strings and mark them Skip, as today. See bz15253
• To help give users the idea that the old syntax is gone, let's get rid of the lctl conf_param command completely, and instead get to it via a setparam option flag

  lctl set_param -P : set the parameter permanently, filesystem-wide.  This command must be run on the MGS node.
       set_param -P -d: delete the permanent parameter setting; the default value will be used at next restart.
  

• Actually, let's keep the old conf_param, but hide it (undocumented). It will call the old mechanism. This provides two safety features:
  • Old clients can still get conf_param updates, even with a new MGS
  • If we haven't completely managed to duplicate the coverage of the old syntax, this gives people a fallback.

Was:
Update, verify, and push upstream patch in bz17471

Issue Links

• duplicates: LU-3155 Permanent parameters with lctl set_pa...

Comments

[Nathan Rutman]

Xyratex-bug-id MRP-272

[Nathan Rutman]

Now being addressed in LU-3155

[Nathan Rutman]

Notes:

• this avoids the "writeconf blows away tunables" problem.
• this double the outstanding lock count on the MGS. However, the "active" lock count remains the same (only the param log will typically change).
• apparently right now, there's no way to lctl conf_param lustre-OST*.foo - each OST needs to be fully named. How did we let that get through?

[Artem Blagodarenko (Inactive)]

http://review.whamcloud.com/6025