Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

ki/Mi/Gi/etc parsed incorrectly when kb_base=1000 #1618

Open
1 task done
kotarou3 opened this issue Aug 27, 2023 · 3 comments · May be fixed by #1827
Open
1 task done

ki/Mi/Gi/etc parsed incorrectly when kb_base=1000 #1618

kotarou3 opened this issue Aug 27, 2023 · 3 comments · May be fixed by #1827

Comments

@kotarou3
Copy link

Please acknowledge the following before creating a ticket

Description of the bug:
When (byte) sizes are specified with the ki/Mi/Gi/etc units, they are parsed as 10³B/10⁶B/10⁹B when kb_base=1000 rather than the expected 2¹⁰B/2²⁰B/2³⁰B.
Notably, if I change the units to kiB/MiB/GiB instead, then they are parsed correctly as 2¹⁰B/2²⁰B/2³⁰B

It seems like ki/Mi/Gi are being parsed as if they didn't have the "i" suffix at all?

Environment:

$ uname -a
Linux home.kota.moe 6.4.0-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.4.4-3 (2023-08-08) x86_64 GNU/Linux
$ lsb_release -d
Description:	Debian GNU/Linux trixie/sid

fio version: fio-3.35

Reproduction steps
Blocksize incorrectly parsed as 4000B

[global]
kb_base=1000
size=1Mi
blocksize=4ki
rw=randread

[read-4ki-qd1]
iodepth=1

read-4ki-qd1: (g=0): rw=randread, bs=(R) 4000B-4000B, (W) 4000B-4000B, (T) 4000B-4000B, ioengine=psync, iodepth=1

Blocksize correctly parsed as 4096B:

[global]
kb_base=1000
size=1MiB
blocksize=4kiB
rw=randread

[read-4ki-qd1]
iodepth=1

read-4ki-qd1: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
@RobertTheBrucey
Copy link

I can see in parse.c:217 that only the cases of (for example k) explicitly accounted for are "kib", "k" and "kb", and it looks like "ki" would be interpreted as "k".
This should be a fairly straightforward fix, and I may try my hand at a pull request for it.

@RobertTheBrucey RobertTheBrucey linked a pull request Oct 16, 2024 that will close this issue
Open
@sitsofe
Copy link
Collaborator

sitsofe commented Oct 16, 2024

This is kind of a duplicate of #1396 ...

@RobertTheBrucey
Copy link

Similar but not quite, this issue is that Ki and KiB are treated differently, while #1396 is about whether or not KiB should ever be interpreted as base 1000 at all.
This issue is clearly unintended, because when would you ever expect that Ki and KiB to represent different units?
Regardless of the decision in #1396 this issue should be fixed to ensure consistency between Ki, KiB and Mi MiB, etc and bring the actual behaviour in line with the documentation which states that the "B" is optional for data units, where it currently is required for EC 80000-13 suffixes like KiB

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Fixes issue where Ki,Mi,Gi,Ti,Pi behave like K,KB etc instead of KiB. RobertTheBrucey/fio
3 participants
@kotarou3 @sitsofe @RobertTheBrucey