incorrect units name abbreviations?

[GoogleCodeExporter]

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

Original issue reported on code.google.com by eugene....@gmail.com on 22 Jun 2011 at 4:57

[GoogleCodeExporter]

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.

Original comment by josiah.c...@gmail.com on 22 Jun 2011 at 8:06

[GoogleCodeExporter]

That would likely be the very least of that notional person's problems.

Original comment by felixga...@gmail.com on 22 Jun 2011 at 8:09

[GoogleCodeExporter]

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.

Original comment by josiah.c...@gmail.com on 22 Jun 2011 at 8:18

[GoogleCodeExporter]

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.

Original comment by felixga...@gmail.com on 22 Jun 2011 at 8:39

[GoogleCodeExporter]

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. ;-)

Original comment by zr40.nl on 22 Jun 2011 at 9:52

[GoogleCodeExporter]

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.

Original comment by josiah.c...@gmail.com on 22 Jun 2011 at 10:55

[GoogleCodeExporter]

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?

Original comment by hampus.w...@gmail.com on 23 Jun 2011 at 6:04