[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 A Simmons]

So I started to look into this and see the reason as John pointed out for the failures Nunez posted is due to the test treating the values returned by say "max_dirty_mb" as a real integer and not a float point string. We could update the test to feed this result into bc since bash can't do floating point math. The question to ask is do we want to make sites do the same kind of crazy? If we don't that means we end implementing round_up() handling like we did for dirty_max_pages. Is that okay with people?

[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