Details
-
Bug
-
Resolution: Fixed
-
Minor
-
Lustre 1.8.6
-
None
-
CentOS 5.6
-
4866
Description
After I change the value of qos_threshold_rr by writing to /proc/fs/lustre/lov/<fsname>-mdtlov/qos_threshold_rr, the value I read back is usually one less than the value I wrote:
[root]# echo 17 > qos_threshold_rr
[root]# cat qos_threshold_rr
16%
This is not the case for values 0 or 100:
[root]# echo 100 > qos_threshold_rr
[root]# cat qos_threshold_rr
100%
[root]# echo 0 > qos_threshold_rr
[root]# cat qos_threshold_rr
0%
I realize this is an artifact of the way the value is stored. (Value range 0-100 is converted to 0-256 when written, and then converted back when read.) However, it is confusing to write one value and then read back a different value. This could be especially problematic when the value is 1:
[root]# echo 1 > qos_threshold_rr
[root]# cat qos_threshold_rr
0%
Anyone reading a value of 0 would not know whether the value had been set to 0 or 1.
If the behavior of Lustre cannot be modified, then the documentation should probably be updated to explain it.
Attachments
Issue Links
- Trackbacks
-
Lustre 1.8.x known issues tracker While testing against Lustre b18 branch, we would hit known bugs which were already reported in Lustre Bugzilla https://bugzilla.lustre.org/. In order to move away from relying on Bugzilla, we would create a JIRA
-
Changelog 1.8 Changes from version 1.8.7wc1 to version 1.8.8wc1 Server support for kernels: 2.6.18308.4.1.el5 (RHEL5) Client support for unpatched kernels: 2.6.18308.4.1.el5 (RHEL5) 2.6.32220.13.1.el6 (RHEL6) Recommended e2fsprogs version: 1.41.90....
-
Changelog 2.2 version 2.2.0 Support for networks: o2iblnd OFED 1.5.4 Server support for kernels: 2.6.32220.4.2.el6 (RHEL6) Client support for unpatched kernels: 2.6.18274.18.1.el5 (RHEL5) 2.6.32220.4.2.el6 (RHEL6) 2.6.32.360....