[LU-6268] lctl in interactive mode fails to parse get_param requests when run after get_param -n

• Status: Resolved
• Project: Lustre
• Affects Version/s: Lustre 2.5.3
• Type: Bug
• Priority: Minor
• Reporter: Josh Lothian (Inactive)
• Assignee: Jian Yu
• Resolution: Duplicate

Environment

Centos 6.5

• Severity: 3

Description

When running lctl interactively, it fails to parse commands when run in a certain order. For example:

12:46:09 (pts/1:skein1.ccs.ornl.gov)% lctl |~/src/melt
lctl > get_param -n osc.*.stats
snapshot_time 1424454461.933397 secs.usecs
req_waittime 234972 samples [usec] 108 5063035 306162221 75801966615113
req_active 234972 samples [reqs] 1 7 241025 255209
read_bytes 33525 samples [bytes] 294912 1048576 35150017444 36855368470308624
write_bytes 59583 samples [bytes] 116 1048576 62473570980 65506751073897104
ost_setattr 20 samples [usec] 362 22779 33394 525105442
ost_read 33525 samples [usec] 1318 108696 110832848 493077777590
ost_write 59583 samples [usec] 1288 5063035 126267741 74861672349603
<snip>
ost_connect 1 samples [usec] 872 872 872 760384
ost_punch 3 samples [usec] 24060 58101 126686 5937085426
ost_statfs 16934 samples [usec] 138 11406 5861480 2518858106
ldlm_cancel 153 samples [usec] 139 10846 79772 207940048
obd_ping 120839 samples [usec] 109 10620 26991886 6713103412
lctl > get_param osc.knotfs-OST0037-osc-ffff8807eab68c00.cur_dirty_bytes
get_param: invalid option – '('
get the Lustre or LNET parameter
usage: get_param [-n|-N|-F] <param_path1 param_path2 ...>
Get the value of Lustre or LNET parameter from the specified path.
The path can contain shell-style filename patterns.
-n Print only the value and not parameter name.
-N Print only matched parameter names and not the values.
(Especially useful when using patterns.)
-F When -N specified, add '/', '@' or '=' for directories,
symlinks and writeable files, respectively.

Issue Links

• duplicates: LU-6267 lctl in interactive mode repeated use...

Comments

[Jodi Levi (Inactive)]

Yu Jian,
Could you please have a look at this one and comment?
Thank you!

[Jian Yu]

Here is the test result with the patch http://review.whamcloud.com/13893 on Lustre b2_5 branch:

# lctl
lctl > get_param -n osc.*.stats
snapshot_time             1424962691.522550 secs.usecs
req_waittime              113 samples [usec] 657 3344 128673 164051411
req_active                113 samples [reqs] 1 1 113 113
ost_connect               1 samples [usec] 3344 3344 3344 11182336
ost_statfs                2 samples [usec] 686 863 1549 1215365
ost_quotactl              8 samples [usec] 717 951 6839 5898499
obd_ping                  102 samples [usec] 657 3148 116941 145755211
snapshot_time             1424962691.522594 secs.usecs
req_waittime              113 samples [usec] 621 3206 127895 159808059
req_active                113 samples [reqs] 1 1 113 113
ost_connect               1 samples [usec] 2594 2594 2594 6728836
ost_statfs                2 samples [usec] 621 747 1368 943650
ost_quotactl              8 samples [usec] 723 911 6497 5310103
obd_ping                  102 samples [usec] 623 3206 117436 146825470
lctl > get_param osc.lustre-OST0000-osc-ffff88007db75c00.cur_dirty_bytes
osc.lustre-OST0000-osc-ffff88007db75c00.cur_dirty_bytes=0
lctl >

The issue can be resolved by the above patch.

[Jian Yu]

Let's close this ticket as a duplicate of LU-6267.