[LU-6688] sanityn 77a and 77b fail to set the NRS policy Created: 04/Jun/15 Updated: 18/Aug/16 Resolved: 16/Aug/16 |
|
| Status: | Resolved |
| Project: | Lustre |
| Component/s: | None |
| Affects Version/s: | Lustre 2.8.0 |
| Fix Version/s: | Lustre 2.9.0 |
| Type: | Bug | Priority: | Minor |
| Reporter: | James Nunez (Inactive) | Assignee: | James Nunez (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Issue Links: |
|
||||||||
| Severity: | 3 | ||||||||
| Rank (Obsolete): | 9223372036854775807 | ||||||||
| Description |
|
Both sanityn test 77a and 77b set the NRS policy on the MDS: test_77a() { #LU-3266
do_facet $SINGLEMDS lctl set_param ost.OSS.*.nrs_policies="fifo"
…
}
run_test 77a "check FIFO NRS policy"
test_77b() { #LU-3266
do_facet $SINGLEMDS lctl set_param ost.OSS.*.nrs_policies="crrn"
do_facet $SINGLEMDS lctl set_param ost.OSS.*.nrs_crrn_quantum=1
…
}
run_test 77b "check CRR-N NRS policy"
The calls to ‘lctl set_param $SINGLEMDS’ are silently failing. In the client test logs, we see: == sanityn test 77a: check FIFO NRS policy == 11:19:01 (1433416741) CMD: shadow-25vm4 lctl set_param ost.OSS.*.nrs_policies=fifo shadow-25vm4: error: set_param: ost/OSS/*/nrs_policies: Found no match and == sanityn test 77b: check CRR-N NRS policy == 11:19:17 (1433416757) CMD: shadow-25vm4 lctl set_param ost.OSS.*.nrs_policies=crrn shadow-25vm4: error: set_param: ost/OSS/*/nrs_policies: Found no match CMD: shadow-25vm4 lctl set_param ost.OSS.*.nrs_crrn_quantum=1 shadow-25vm4: error: set_param: ost/OSS/*/nrs_crrn_quantum: Found no match policy: crr-n, crrn_quantum 1 CMD: shadow-25vm5,shadow-25vm6.shadow.whamcloud.com sync CMD: shadow-25vm4 lctl set_param ost.OSS.*.nrs_crrn_quantum=64 shadow-25vm4: error: set_param: ost/OSS/*/nrs_crrn_quantum: Found no match policy: crr-n, crrn_quantum 64 One example of test logs with these errors is at https://testing.hpdd.intel.com/test_sets/3f006138-0ad1-11e5-88ab-5254006e85c2 The problem is, looking on the MDS, there is no /proc/fs/lustre/ost directory. Since these test are only setting the NRS policy and writing data to files, it may not matter if the NRS policy is set on the MDS(s) or OST(s). |
| Comments |
| Comment by Andreas Dilger [ 04/Jun/15 ] |
|
For DNE testing it would be possible to set the CRR policies on all the MDSes, so they should use do_nodes $(comma_list $(mdts_nodes)) so that it is set on all the MDS nodes consistently, since we don't know which one will be used for the test. However, the nrs_write_read() test is mostly doing IO, so it may be better to also set it on the OSS nodes by adding $(osts_nodes) into the list. Each of these sub-tests should return the policy back to the original policy. The orr_trr() function may should also use do_nodes instead of explicitly looping through all the OST index values separately. It doesn't make sense to set the ORR policy on the MDS nodes, since it is sorting based on IO object and offset. All of these policy settings should verify that there is no error returned, and in nrs_write_read() it should also check for errors returned by "dd". |
| Comment by Gerrit Updater [ 05/Aug/16 ] |
|
James Simmons (uja.ornl@yahoo.com) uploaded a new patch: http://review.whamcloud.com/21764 |
| Comment by James A Simmons [ 05/Aug/16 ] |
|
Since this blocking my |
| Comment by Gerrit Updater [ 15/Aug/16 ] |
|
Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/21764/ |
| Comment by James A Simmons [ 16/Aug/16 ] |
|
Patched landed. |