From: Martin Steigerwald <martin.steigerwald@teamix.de>
To: FIO mailing list <fio@vger.kernel.org>
Cc: Jens Axboe <axboe@kernel.dk>, 872321@bugs.debian.org
Subject: fio: uses the opposite symbol for kibibytes/kilobytes (Kb/KiB) than ISO 80000-1
Date: Mon, 28 Aug 2017 11:06:26 +0200 [thread overview]
Message-ID: <7412967.4hxrjql1Vb@merkaba> (raw)
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 ***
next reply other threads:[~2017-08-28 9:06 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-28 9:06 Martin Steigerwald [this message]
2017-10-24 8:06 ` fio: uses the opposite symbol for kibibytes/kilobytes (Kb/KiB) than ISO 80000-1 Martin Steigerwald
2017-10-24 16:23 ` Elliott, Robert (Persistent Memory)
2017-10-26 8:42 ` Martin Steigerwald
2017-10-24 8:13 ` Martin Steigerwald
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7412967.4hxrjql1Vb@merkaba \
--to=martin.steigerwald@teamix.de \
--cc=872321@bugs.debian.org \
--cc=axboe@kernel.dk \
--cc=fio@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.