[LU-11157] sanity test_42e: invalid arithmetic operator (error token is ".9")

• Type: Bug
• Resolution: Fixed
• Priority: Minor
• Fix Version/s: Lustre 2.13.0, Lustre 2.12.4
• Affects Version/s: Lustre 2.12.0
• Severity: 3
• Assignee: James A Simmons
• Reporter: Maloo

Description

This issue was created by maloo for John Hammond <[e-mail]>

This issue relates to the following test suite run: https://testing.whamcloud.com/test_sets/f2a78f4c-8aa6-11e8-808e-52540065bddc

test_42e failed with the following error:

test_42e returned 1

== sanity test 42e: verify sub-RPC writes are not done synchronously ================================= 14:42:04 (1531924924)
total: 3500 open/close in 6.19 seconds: 565.32 ops/second
/usr/lib64/lustre/tests/sanity.sh: line 3978: 209.9: syntax error: invalid arithmetic operator (error token is ".9")

Some proc/sys/... files are returning decimal values. This one is from max_dirty_mb.

Looks like 14 instances of this failure today.

VVVVVVV DO NOT REMOVE LINES BELOW, Added by Maloo for auto-association VVVVVVV
sanity test_42e - test_42e returned 1

Issue Links

• is related to: LU-8066 Move lustre procfs handling to sysfs and debugfs.
• is related to: LU-10990 Get rid of per-osc max_dirty_mb setting
• is related to: LU-9091 Replace lprocfs_str_with_units_to_s64 with string_get_size()

Comments

[James Nunez (Inactive)]

In addition to sanity test 42e failing, we also see the following tests fail:
sanity 64d with the same error message; '209.9: syntax error: invalid arithmetic operator (error token is ".9")'
conf-sanity test 76a with error message ''209.9: syntax error: invalid arithmetic operator (error token is ".9")'
recovery-small test 55 with error 'error: set_param: setting /sys/fs/lustre/osc/lustre-OST0001-osc-ffff9b4353f50800/max_dirty_mb=209.9: Invalid argument'
sanity-dom test 42e, which is running sanity test 42e

[Gerrit Updater]

Andreas Dilger ([e-mail]) merged in patch https://review.whamcloud.com/32831/
Subject: LU-11157 obd: keep dirty_max_pages a round number of MB
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: d3f88d376c49e4520a0d695a4b4e9b0c2dbebaaf

[John Hammond]

> Ouch, it been broken upstream for some time.

It was only when LU-10990 and LU-8066 were combined that this started failing.

I am really not a fan of displaying decimal fractional values in these files. Generally it means that we cannot faithfully save and restore the parameter values.

However if we do keep fractional values then I think there is more to do here. There are substantial differences between lprocfs_seq_read_frac_helper() and lprocfs_read_frac_helper(). I don't know why the second function is so complicated. But this is bad. Switching from proc to sys shouldn't be changing the format used to display the values.

[James A Simmons]

Ouch, it been broken upstream for some time.

[Andreas Dilger]

LU-8066 obdclass: move lustre sysctl to sysfs
    
    Backport from upstream the changes to port lustre
    systctl to sysfs. Needed to re-export the function
    lprocfs_read_frac_helper for later work. The
    following patches were backported:
    
    Linux-commit: e2424a1265f2772b66f068c205256e2aef5f74a0
    
    Move max_dirty_mb from sysctl to sysfs. max_dirty_mb is
    now a parameter in /sys/fs/lustre.

[Gerrit Updater]

John L. Hammond ([e-mail]) uploaded a new patch: https://review.whamcloud.com/32831
Subject: LU-11157 obd: keep dirty_max_pages a round number of MB
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 2c46819ed70b222a8b762d1b2e7e1f4226de89e8