Uploaded image for project: 'Lustre'
  1. Lustre
  2. LU-4221

lctl conf_param <obdname>.ost.writethrough_cache_enable=N does not work anymore

Details

    • Bug
    • Resolution: Fixed
    • Blocker
    • Lustre 2.6.0, Lustre 2.5.1
    • Lustre 2.6.0
    • None
    • 3
    • 11487

    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
      

      Attachments

        Activity

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

          James, the uncertainty I have is that I think this patch will allow this specific parameter to be set, but it will result in warnings for every other OFD parameter that is not in the OSD. If I'm incorrect in this understanding, then I'm happier to land the patch.

          adilger Andreas Dilger added a comment - James, the uncertainty I have is that I think this patch will allow this specific parameter to be set, but it will result in warnings for every other OFD parameter that is not in the OSD. If I'm incorrect in this understanding, then I'm happier to land the patch.
          simmonsja James A Simmons added a comment - - edited

          Did testing with the latest patch and works as expected. No more complaining as well. Thanks.

          simmonsja James A Simmons added a comment - - edited Did testing with the latest patch and works as expected. No more complaining as well. Thanks.
          emoly.liu Emoly Liu added a comment -

          Yes, James, this error was reported because obdfilter didn't match the parameter in its static lproc var list, and then it passed the parameter to next module osd.

          Andreas, IMHO, I want to pass the parent entry to get the whole sub entries list, but it's not so easy to follow the link to get the target.

          emoly.liu Emoly Liu added a comment - Yes, James, this error was reported because obdfilter didn't match the parameter in its static lproc var list, and then it passed the parameter to next module osd. Andreas, IMHO, I want to pass the parent entry to get the whole sub entries list, but it's not so easy to follow the link to get the target.

          I guess the obdfilter code is complaining because it is processing the "ost" parameter, but the named parameter doesn't exist. This is desirable under normal usage.

          It probably makes sense to add an explicit skip of this parameter name in the obdfilter config processing code, if that is possible. There may be a couple of other parameters that moved from obdfilter to osd that should also be skipped in obdfilter.

          adilger Andreas Dilger added a comment - I guess the obdfilter code is complaining because it is processing the "ost" parameter, but the named parameter doesn't exist. This is desirable under normal usage. It probably makes sense to add an explicit skip of this parameter name in the obdfilter config processing code, if that is possible. There may be a couple of other parameters that moved from obdfilter to osd that should also be skipped in obdfilter.

          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.

          simmonsja James A Simmons added a comment - 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 Emoly Liu added a comment -
          emoly.liu Emoly Liu added a comment - patch tracking at: http://review.whamcloud.com/8238

          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.

          simmonsja James A Simmons added a comment - 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 Emoly Liu added a comment -

          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 Emoly Liu added a comment - 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 Emoly Liu added a comment -

          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 Emoly Liu added a comment - 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 Emoly Liu added a comment -

          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.

          emoly.liu Emoly Liu added a comment - 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.

          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.

          simmonsja James A Simmons added a comment - 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.

          People

            emoly.liu Emoly Liu
            mjmac Michael MacDonald (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: