[LU-4221] lctl conf_param <obdname>.ost.writethrough_cache_enable=N does not work anymore

• Type: Bug
• Resolution: Fixed
• Priority: Blocker
• Fix Version/s: Lustre 2.6.0, Lustre 2.5.1
• Affects Version/s: Lustre 2.6.0
• Severity: 3
• Assignee: Emoly Liu
• Reporter: Michael MacDonald (Inactive)

Description

Using 2.5.0 RC1, which I assume is what went GA.

In previous releases of Lustre, it was possible to set this tunable via conf_param, but now it doesn't work:

[root@mgs ~]# lctl conf_param testfs-OST0000.ost.writethrough_cache_enable=0
[root@mgs ~]# cat /proc/fs/lustre/obdfilter/testfs-OST0000/writethrough_cache_enable
1

The command completes successfully, but we see the following in dmesg:

LustreError: 15418:0:(obd_config.c:1341:class_process_proc_param()) testfs-OST0000: unknown param writethrough_cache_enable=0
LustreError: 15418:0:(obd_config.c:1591:class_config_llog_handler()) MGC10.42.42.5@tcp: cfg command failed: rc = -38
Lustre:    cmd=cf00f 0:testfs-OST0000  1:ost.writethrough_cache_enable=0

I understand that conf_param is on its way to being deprecated, and that set_param -P is preferred. However, conf_param should still work, right? It seems that some things still work as they always have, e.g.:

[root@mgs ~]# lctl conf_param testfs-OST0000.ost.client_cache_seconds=4242
[root@mgs ~]# cat /proc/fs/lustre/obdfilter/testfs-OST0000/client_cache_seconds
4242

In dmesg:

Lustre: Modifying parameter testfs-OST0000.ost.client_cache_seconds in log testfs-OST0000

Comments

[James A Simmons]

Testing with your patch I'm getting.

[root@spoon45 tests]# lctl conf_param lustre-OST0000.ost.writethrough_cache_enable=1
[root@spoon45 tests]# dmesg
[ 1383.895301] Lustre: Modifying parameter lustre-OST0000.ost.writethrough_cache_enable in log lustre-OST0000
[ 1392.871703] LustreError: 20254:0:(obd_config.c:1341:class_process_proc_param()) lustre-OST0000: unknown param writethrough_cache_enable=1
[root@spoon45 tests]# cat /proc/fs/lustre/obdfilter/lustre-OST0000/writethrough_cache_enable
1

Its doing the right thing but I see a error reported in dmesg. Other than that the patch fixed this problem.

[Emoly Liu]

patch tracking at: http://review.whamcloud.com/8238

[James A Simmons]

Sorry I have been busy with LU-3373/LU-3319 work. Sounds like you have a better solution than what I have. I look forward to applying your solution to my work.

[Emoly Liu]

Thanks for fanyong's advice. We don't need to pass parent entry to get all the sub entries or try to resolve symbolic link path, instead, just pass conf param down the stack to let osd process it.

I add case LCFG_PARAM to osd_process_config() and now it can recognize these symlink params.

I will submit the patch later.

[Emoly Liu]

I have a tentative patch without lprocfs_srch(). Now the problem is that how to get the real target proc entry, because the symlink entry has no read/write_proc.
I think there should be a better way than resolving the link path stored in entry->data.

[Emoly Liu]

James, thanks for your information! I know you are working on LU-3319. Did you try the command "lctl conf_param testfs-OST0000.ost.writethrough_cache_enable=0"? Could you please provide more logs or dmesg?

Thanks.

[James A Simmons]

I noticed this ticket and I have been working on moving all the proc code over to the seq_file. With newer kernels you can no longer transverse the tree with lprocfs_srch so I cached the parent proc entry in struct obd_device. Just tried this with my work. I instead get a

[76965.678055] LustreError: 23899:0:(mgs_handler.c:744:mgs_iocontrol()) MGS: setparam err: rc = -22
[77095.862258] LustreError: 24014:0:(mgs_llog.c:335:mgs_new_fsdb()) fsname obdfilter is too long

If this is a problem for obdfilter I better it is broken for other things as well.

[Emoly Liu]

If we can get parent proc entry, calling lprocfs_srch() to find the param in class_process_proc_param() should be easier than updating the list in xxx_process_config().

I am working on the patch.

[Emoly Liu]

The root cause is that these symlink entries are not included by lproc variable list in ofd_process_config(). So, when searching through the list, the symlink can't be matched and ENOSYS is reported.

static int ofd_process_config(const struct lu_env *env, struct lu_device *d,
                              struct lustre_cfg *cfg)
{
...
        switch (cfg->lcfg_command) {
        case LCFG_PARAM: {
                struct lprocfs_static_vars lvars;
...
                lprocfs_ofd_init_vars(&lvars);
                rc = class_process_proc_param(PARAM_OST, lvars.obd_vars, cfg,
                                              d->ld_obd);
}

void lprocfs_ofd_init_vars(struct lprocfs_static_vars *lvars)
{                               
        lvars->module_vars  = lprocfs_ofd_module_vars;
        lvars->obd_vars     = lprocfs_ofd_obd_vars;
}   

This list is initialized by lprocfs_ofd_init_vars(), while those symlink ones are defined in ofd_procfs_add_brw_stats_symlink() separately.

We need to re-add the missing symlinks to the list.

[Emoly Liu]

I will verify/investigate the symlink issue questioned by Andreas.

[Peter Jones]

Emoly

Could you please look into this one?

Thanks

Peter