fio: uses the opposite symbol for kibibytes/kilobytes (Kb/KiB) than ISO 80000-1

fio: uses the opposite symbol for kibibytes/kilobytes (Kb/KiB) than ISO 80000-1

[Martin Steigerwald]

I bcc´ed Debian bug report for this initial mail so it receives a record that 
I forwarded this issue upstream.


Hello Jens,

I got this bug report for fio Debian package:

fio: uses the opposite symbol for kibibytes/kilobytes (Kb/KiB) than ISO 80000-1
https://bugs.debian.org/872321

Its right. Completely right. The current behavior of fio is broken.

But if I choose to divert from upstream default, I break *all included 
examples* unless I patch them up to and I risk bug reports "my script broke 
cause you decided to divert from upstream default behavior". Additionally 
currently it seems to me that I have to patch fio source code, unless fio 
supports a global configuration file in /etc, which, I believe, it does not.

What do you suggest me to do?

I am currently pondering the following options:

- Adding a warning note to NEWS.Debian and README.Debian that at least users 
who have apt-listchanges installed will see.

- Add a debconf configuration option aka "Yes, be correct and break all 
scripts", "No, let me stay compatible with upstream". But that wouldn´t 
possible anyway unless there is a global configuration file for fio.

None of these options sound appealing to me.


I really think this issue needs to be dealt with upstream, but I honestly do 
not know how either. But just staying with the broken behavior for eternity 
does not seem right to me. I think the move to fio 3 would have been an 
opportunity, but thats gone.

I wonder about the following compromize:

- blocksize=4k => KiB, 4096
- blocksize=4kb => KB, 4000
- blocksize=4kib => KiB, 4096

This at least won´t break existing scripts unless they used kib, gib and so 
on, I think.

And it would at least fix:

% fio --name=rand-read --bs=4k --size=1GiB --iodepth=64 --runtime=10 --
rw=randread
[…]
rand-read: Laying out IO file(s) (1 file(s) / 953MiB)
[…]

which is just as broken as it can become. Seriously, 1 GiB is not 953 MiB. 
Period.


Even if thats an uncomfortable issue to deal with, I honestly don´t really see 
it as my responsibility as a package maintainer to fix up broken upstream 
behavior and probably receive the blame for doing so. If you choose to stay 
with the current behavior I may at least add a note in NEWS.Debian and 
README.Debian about the broken behavior tough.

Thanks,

-- 
Martin Steigerwald  | Trainer

teamix GmbH
Südwestpark 43
90449 Nürnberg

Tel.:  +49 911 30999 55 | Fax: +49 911 30999 99
mail: martin.steigerwald@teamix.de | web:  http://www.teamix.de | blog: http://blog.teamix.de

Amtsgericht Nürnberg, HRB 18320 | Geschäftsführer: Oliver Kügow, Richard Müller, Jason Clark, Jakob Høholdt

teamix Support Hotline: +49 911 30999-112
 
 *** Bitte liken Sie uns auf Facebook: facebook.com/teamix ***

Re: fio: uses the opposite symbol for kibibytes/kilobytes (Kb/KiB) than ISO 80000-1

[Martin Steigerwald]

Hello Jens, hello fio community.

Anything? Anything at all?

If not, I go by a NEWS.Debian entry that explains the issue, but otherwise I 
tend to leave intact the broken, but wide-spread default behavior.

Thanks,
Martin

Martin Steigerwald - 28.08.17, 11:06:
> I bcc´ed Debian bug report for this initial mail so it receives a record
> that I forwarded this issue upstream.
> 
> 
> Hello Jens,
> 
> I got this bug report for fio Debian package:
> 
> fio: uses the opposite symbol for kibibytes/kilobytes (Kb/KiB) than ISO
> 80000-1 https://bugs.debian.org/872321
> 
> Its right. Completely right. The current behavior of fio is broken.
> 
> But if I choose to divert from upstream default, I break *all included
> examples* unless I patch them up to and I risk bug reports "my script broke
> cause you decided to divert from upstream default behavior". Additionally
> currently it seems to me that I have to patch fio source code, unless fio
> supports a global configuration file in /etc, which, I believe, it does not.
> 
> What do you suggest me to do?
> 
> I am currently pondering the following options:
> 
> - Adding a warning note to NEWS.Debian and README.Debian that at least users
> who have apt-listchanges installed will see.
> 
> - Add a debconf configuration option aka "Yes, be correct and break all
> scripts", "No, let me stay compatible with upstream". But that wouldn´t
> possible anyway unless there is a global configuration file for fio.
> 
> None of these options sound appealing to me.
> 
> 
> I really think this issue needs to be dealt with upstream, but I honestly do
> not know how either. But just staying with the broken behavior for eternity
> does not seem right to me. I think the move to fio 3 would have been an
> opportunity, but thats gone.
> 
> I wonder about the following compromize:
> 
> - blocksize=4k => KiB, 4096
> - blocksize=4kb => KB, 4000
> - blocksize=4kib => KiB, 4096
> 
> This at least won´t break existing scripts unless they used kib, gib and so
> on, I think.
> 
> And it would at least fix:
> 
> % fio --name=rand-read --bs=4k --size=1GiB --iodepth=64 --runtime=10 --
> rw=randread
> […]
> rand-read: Laying out IO file(s) (1 file(s) / 953MiB)
> […]
> 
> which is just as broken as it can become. Seriously, 1 GiB is not 953 MiB.
> Period.
> 
> 
> Even if thats an uncomfortable issue to deal with, I honestly don´t really
> see it as my responsibility as a package maintainer to fix up broken
> upstream behavior and probably receive the blame for doing so. If you
> choose to stay with the current behavior I may at least add a note in
> NEWS.Debian and README.Debian about the broken behavior tough.
> 
> Thanks,




Mit freundlichen Grüßen / With kind regards

Martin Steigerwald • Proact Deutschland GmbH
Trainer

Telefon: +49 911 30999 55 • Fax: +49 911 30999 99
Südwestpark 43 • 90449 Nürnberg • Germany
Martin.Steigerwald@proact.de • www.proact.de

Amtsgericht Nürnberg • HRB 18320
Geschäftsführer: Oliver Kügow • Richard Müller • Jason Clark • Jakob Høholdt

This email and its attachments may be confidential and are intended solely 
for the use of the individual to whom it is addressed fio@vger.kernel.org, axboe@kernel.dk. Any views or opinions 
expressed are solely those of the author Martin Steigerwald and do not necessarily 
represent those of Proact Deutschland GmbH. If you have received this message in error, 
please notify us immediately by replying to the message and deleting it from 
your computer. We do not accept responsibility for any errors or omissions that 
are present in this message, or any attachment, that have arisen as a result of 
email transmission.

RE: fio: uses the opposite symbol for kibibytes/kilobytes (Kb/KiB) than ISO 80000-1

[Elliott, Robert (Persistent Memory)]

> > I got this bug report for fio Debian package:
> >
> > fio: uses the opposite symbol for kibibytes/kilobytes (Kb/KiB) than
> ISO 80000-1 https://bugs.debian.org/872321
> >
> > Its right. Completely right. The current behavior of fio is broken.
> >
> > But if I choose to divert from upstream default, I break *all included
> > examples* unless I patch them up to and I risk bug reports "my script broke
> > cause you decided to divert from upstream default behavior".

No scripts were harmed in the process; the default still presumes that
scripts are specifying numbers based on binary units.  You must add 
kb_base=1000 to switch to correct units.

The user-readable text output changed to use correct units, but the
structured output formats intended for automated parsing did not change.


---
Robert Elliott, HPE Persistent Memory

Re: fio: uses the opposite symbol for kibibytes/kilobytes (Kb/KiB) than ISO 80000-1

[Martin Steigerwald]

Hello Robert.

Elliott, Robert (Persistent Memory) - 24.10.17, 16:23:
> > > I got this bug report for fio Debian package:
> > >
> > >
> > >
> > > fio: uses the opposite symbol for kibibytes/kilobytes (Kb/KiB) than

Sorry for safelink crap. (Need to remember to use my own SMTP to circumvent 
it.)

> https://bugs.debian.org/872321
>
> > > Its right. Completely right. The current behavior of fio is broken.
> > >
> > >
> > >
> > > But if I choose to divert from upstream default, I break *all included
> > > examples* unless I patch them up to and I risk bug reports "my script
> > > broke cause you decided to divert from upstream default behavior".
> 
> 
> No scripts were harmed in the process; the default still presumes that
> scripts are specifying numbers based on binary units.  You must add 
> kb_base=1000 to switch to correct units.

I don´t really understand this one. If I would change fio´s default behavior, I 
bet scripts may break. I wouldn´t change the meaning of "k" anyway, but just 
of "kib" and "kb", but still if a script uses one of these, it would break.

Additionally I would need to patch fio source code as I am not aware of any 
other way to change this default behavior.

I decided that I won´t do that.

So unless any change in upstream I will do with the README approach.

However, likely after an initial fio 3.1 Debian package uploaded is done. I 
just asked my sponsor Sven Hoexter to review the package.

> The user-readable text output changed to use correct units, but the
> structured output formats intended for automated parsing did not change.

Hmm, interesting.

Thanks,
Martin

Re: fio: uses the opposite symbol for kibibytes/kilobytes (Kb/KiB) than ISO 80000-1

[Martin Steigerwald]

Send again without that long and misleading mail signature. Sorry for noise.


Hello Jens, hello fio community.

Anything? Anything at all?

If not, I go by a NEWS.Debian entry that explains the issue, but otherwise I 
tend to leave intact the broken, but wide-spread default behavior.

Thanks,
Martin

Martin Steigerwald - 28.08.17, 11:06:
> I bcc´ed Debian bug report for this initial mail so it receives a record
> that I forwarded this issue upstream.
> 
> 
> Hello Jens,
> 
> I got this bug report for fio Debian package:
> 
> fio: uses the opposite symbol for kibibytes/kilobytes (Kb/KiB) than ISO
> 80000-1 https://bugs.debian.org/872321
> 
> Its right. Completely right. The current behavior of fio is broken.
> 
> But if I choose to divert from upstream default, I break *all included
> examples* unless I patch them up to and I risk bug reports "my script broke
> cause you decided to divert from upstream default behavior". Additionally
> currently it seems to me that I have to patch fio source code, unless fio
> supports a global configuration file in /etc, which, I believe, it does not.
> 
> What do you suggest me to do?
> 
> I am currently pondering the following options:
> 
> - Adding a warning note to NEWS.Debian and README.Debian that at least users
> who have apt-listchanges installed will see.
> 
> - Add a debconf configuration option aka "Yes, be correct and break all
> scripts", "No, let me stay compatible with upstream". But that wouldn´t
> possible anyway unless there is a global configuration file for fio.
> 
> None of these options sound appealing to me.
> 
> 
> I really think this issue needs to be dealt with upstream, but I honestly do
> not know how either. But just staying with the broken behavior for eternity
> does not seem right to me. I think the move to fio 3 would have been an
> opportunity, but thats gone.
> 
> I wonder about the following compromize:
> 
> - blocksize=4k => KiB, 4096
> - blocksize=4kb => KB, 4000
> - blocksize=4kib => KiB, 4096
> 
> This at least won´t break existing scripts unless they used kib, gib and so
> on, I think.
> 
> And it would at least fix:
> 
> % fio --name=rand-read --bs=4k --size=1GiB --iodepth=64 --runtime=10 --
> rw=randread
> […]
> rand-read: Laying out IO file(s) (1 file(s) / 953MiB)
> […]
> 
> which is just as broken as it can become. Seriously, 1 GiB is not 953 MiB.
> Period.
> 
> 
> Even if thats an uncomfortable issue to deal with, I honestly don´t really
> see it as my responsibility as a package maintainer to fix up broken
> upstream behavior and probably receive the blame for doing so. If you
> choose to stay with the current behavior I may at least add a note in
> NEWS.Debian and README.Debian about the broken behavior tough.
> 
> Thanks,