Issue 592 in redis: incorrect units name abbreviations?
re...@googlecode.com
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 592 by eugene....@gmail.com: incorrect units name abbreviations?
http://code.google.com/p/redis/issues/detail?id=592
What version of Redis you are using, in what kind of Operating System?
2.2.10
What is the problem you are experiencing?
redis is using incorrect abbreviations for memory sizes
What steps will reproduce the problem?
cat /etc/redis.conf | head -20
Do you have an INFO output? Please past it here.
# Note on units: when memory size is needed, it is possible to specifiy
# it in the usual form of 1k 5GB 4M and so forth:
#
# 1k => 1000 bytes
# 1kb => 1024 bytes
# 1m => 1000000 bytes
# 1mb => 1024*1024 bytes
# 1g => 1000000000 bytes
# 1gb => 1024*1024*1024 bytes
If it is a crash, can you please paste the stack trace that you can find in
the log file or on standard output? This is really useful for us!
Please provide any additional information below.
I don't expect anyone to pay real attention to this :)
But standartizes unit names exist for over 10 years:
http://physics.nist.gov/cuu/Units/binary.html,
http://en.wikipedia.org/wiki/Binary_prefix
so this likely should be:
#
# 1kb => 1000 bytes
# 1kib => 1024 bytes
# 1mb => 1000000 bytes
# 1mib => 1024*1024 bytes
# 1gb => 1000000000 bytes
# 1gib => 1024*1024*1024 bytes
re...@googlecode.com
Comment #1 on issue 592 by josiah.c...@gmail.com: incorrect units name
abbreviations?
http://code.google.com/p/redis/issues/detail?id=592
Changing the meaning of configuration options would negatively affect
anyone who would choose to upgrade Redis without taking the time to
manually upgrade their configuration.
re...@googlecode.com
Comment #2 on issue 592 by felixga...@gmail.com: incorrect units name
abbreviations?
http://code.google.com/p/redis/issues/detail?id=592
That would likely be the very least of that notional person's problems.
re...@googlecode.com
Comment #3 on issue 592 by josiah.c...@gmail.com: incorrect units name
abbreviations?
http://code.google.com/p/redis/issues/detail?id=592
Felix: please expand, I must be missing something. I've not altered my
configuration in the last year, despite upgrading Redis multiple times. It
has worked great, as all software with sane configuration should.
re...@googlecode.com
Comment #4 on issue 592 by felixga...@gmail.com: incorrect units name
abbreviations?
http://code.google.com/p/redis/issues/detail?id=592
It's entirely possible to upgrade software without reading the README,
understanding why the upgrade is happening, understanding the ramifications
of any changes on the configuration file, and so forth.
Nevertheless it turns out that the union of the set of all people who
would do such a thing, and the set of people who are redis's actual target
audience, is essentially zero. Redis is not an end user tool, and to treat
it as such is to invite total disaster, because the 'sweet spot' use case
for redis is at the core of a highly tuned systems orchestration.
And further, you are incorrect in your initial statement: the proposed
change would negatively affect only the set of those people to whom the
difference in the configuration file between 1,000,000,000 and 1024^3
(1,073,741,824) is a make or break difference in behavior, and whom
additionally did not understand an upgrade before applying it, and
additionally do not read the redis mailing list, and additionally are still
able to wake up in the morning without accidentally forgetting to breathe.
re...@googlecode.com
Comment #5 on issue 592 by zr40.nl: incorrect units name abbreviations?
http://code.google.com/p/redis/issues/detail?id=592
If such a difference is significant enough to make a real impact, one would
use the 'bytes' unit instead to specify the size.
There are two issues here that would be caused by changing the units:
1. Half of the units (k, m, g) would become invalid. This is what Josiah is
referring to.
This is merely annoying; the user would detect this when Redis fails to
start. He can then fix the config and start Redis.
2. The other half of the units (kb, mb, gb) would shrink a bit. This is
what Felix is referring to.
This only affects the maxmemory option. (And vm-max-memory/vm-page-size,
but these will be going away in 2.4 anyway.)
I don't see any objection against making this change.
Also, while I support the change itself (whole number units are just easier
to use by humans), I disagree with the reason it is presented. Just being a
standard doesn't mean it should be used. Otherwise, Redis would be
communicating using XML, using Protocol Buffers for the .rdb file and JSON
for the AOF. ;-)
re...@googlecode.com
Comment #6 on issue 592 by josiah.c...@gmail.com: incorrect units name
abbreviations?
http://code.google.com/p/redis/issues/detail?id=592
Felix: do you honestly believe and expect that developers and end users
read the full content of every README file for every piece of software they
install or upgrade?
I'm sorry if I have somehow offended your sensibilities in raising concerns
about people having Redis stop working for them (where it had previously
worked). My Python background and general belief that "practicality beats
purity" makes me less concerned about the pedantry of getting size
abbreviations perfect.
A work-around for my concern (Redis not working) would simply be to
silently accept 'k', 'm', and 'g' as equivalents for the
updated 'kb', 'mb', and 'gb'. Which (based on my experience talking with
other Redis users) is far more likely to result in less pain than the
change in sizes for the 'kb', 'mb', and 'gb' abbreviations.
re...@googlecode.com
Comment #7 on issue 592 by hampus.w...@gmail.com: incorrect units name
abbreviations?
http://code.google.com/p/redis/issues/detail?id=592
I like the proposed change. The change could certainly be annoying or
problematic for some people when upgrading, though.
One way to get around most of that would be to make the new units case
sensitive and keep the old ones with a deprecation warning. I think most
people use lower cases right now (probably not everyone). The new units
should be case sensitive anyway IMHO. For example, kb usually means kilobit
and not kilobyte (kB) so if we want to be pedantic...
These would be the new units:
# 1kB => 1000 bytes
# 1KiB => 1024 bytes
# 1MB => 1000000 bytes
# 1MiB => 1024*1024 bytes
# 1GB => 1000000000 bytes
# 1GiB => 1024*1024*1024 bytes
If a unit didn't match any of the new ones, we would check the old ones
(case insensitively) and print a deprecation warning on match:
# 1k => 1000 bytes
# 1kb => 1024 bytes
# 1m => 1000000 bytes
# 1mb => 1024*1024 bytes
# 1g => 1000000000 bytes
# 1gb => 1024*1024*1024 bytes
Anyone else who agree about case sensitivity?