### Please describe the problem.

`git annex status` inconsistently uses mebi (SI) and giga (informal) prefixes.

### What steps will reproduce the problem?

Example:

[[!format txt """
anarcat@marcos:mp3$ git annex status
supported backends: SHA256E SHA1E SHA512E SHA224E SHA384E SHA256 SHA1 SHA512 SHA224 SHA384 WORM URL
supported remote types: git S3 bup directory rsync web glacier hook
repository mode: direct
trusted repositories: 0
semitrusted repositories: 2
        00000000-0000-0000-0000-000000000001 -- web
        b7802161-c984-4c9f-8d05-787a29c41cfe -- here (anarcat@marcos:/srv/mp3)
untrusted repositories: 0
transfers in progress: none
available local disk space: 31.93 gigabytes (+1 megabyte reserved)
local annex keys: 19913
local annex size: 111.08 gigabytes
known annex keys: 20085
known annex size: 111.38 gigabytes
bloom filter size: 16 mebibytes (3.1% full)
backend usage:
        SHA256E: 39998
"""]]

Notice `mebibytes` and `gigabytes`. It is unclear whether those are gigabytes (1000^3) or gibibytes (1024^3).

### What version of git-annex are you using? On what operating system?

4.20130802~bpo70+2, Debian wheezy.

### Please provide any additional information below.

nil. --[[anarcat]]

> git-annex consistently uses the powers of ten units
> for disk storage sizes. Its "gigabyte" is the SI gigabyte.
> 
> It uses the absurdly named units for powers of 2 for memory sizes,
> in the few places it deals with memory (probably only the above bloom
> filter size number). 
> 
> AFAIK I am complying with all relevant standards and best practices.
> Even though I consider them rather dumb, as is clear if you
> [read the opionated source code I wrote to handle this]().
> 
> If git-annex used "gibibyte", the numbers it reports for disk size
> would not match the numbers disk vendors and most tools use.
> 
> [[bug_is_in_world_not_in_git-annex|done]] --[[Joey]]