My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 592: incorrect units name abbreviations?
1 person starred this issue and may be notified of changes. Back to list
Status:  New
Owner:  ----

Sign in to add a comment
Reported by, Jun 22, 2011
What version of Redis you are using, in what kind of Operating System?

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:,

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
Jun 22, 2011
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.
Jun 22, 2011
That would likely be the very least of that notional person's problems.
Jun 22, 2011
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.
Jun 22, 2011
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.

Jun 22, 2011
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. ;-)
Jun 22, 2011
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.
Jun 22, 2011
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?
Sign in to add a comment

Powered by Google Project Hosting