[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

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/36393/
Subject: LU-11157 obd: round values to nearest MiB for *_mb syfs files
Project: fs/lustre-release
Branch: b2_12
Current Patch Set:
Commit: 72c2d383c3e77206b0d169d894a18b5e43b7b72b

[Gerrit Updater]

Minh Diep ([e-mail]) uploaded a new patch: https://review.whamcloud.com/36393
Subject: LU-11157 obd: round values to nearest MiB for *_mb syfs files
Project: fs/lustre-release
Branch: b2_12
Current Patch Set: 1
Commit: 350b4ee688585c034f0c0e520e2587aa4d389eda

[Peter Jones]

Landed for 2.13

[Gerrit Updater]

Oleg Drokin ([e-mail]) merged in patch https://review.whamcloud.com/34317/
Subject: LU-11157 obd: round values to nearest MiB for *_mb syfs files
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: ba2817fe3ead1b8e32be6d6c6ce25b490626118a

[Gerrit Updater]

James Simmons ([e-mail]) uploaded a new patch: https://review.whamcloud.com/34317
Subject: LU-11157 obd: round values to nearest MiB for *_mb sysfs files
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 3e9d90e56042d5ff9076ae057c1ff117c348b2fa

[Andreas Dilger]

I'm fine with rounding the output to a whole number of MB. This is the only code that is using lprocfs_read_frac_helper() so it could just be removed. There are other places that are using lprocfs_seq_read_frac_helper() that will have the same issues. Back when this code was written, a few MB was a lot of memory, but now it is a rounding error for a client.

[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?