git-annex/doc/bugs/inconsistent_use_of_SI_prefixes.mdwn
Joey Hess c0e97b0c60 typo
2013-08-22 12:22:11 -04:00

55 lines
1.8 KiB
Markdown

### 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.
> 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]]