Skip to content
This repository has been archived by the owner on Oct 30, 2018. It is now read-only.

Storjshare status reports incorrect units for bytes #265

Closed
oneup40 opened this issue Oct 2, 2017 · 9 comments
Closed

Storjshare status reports incorrect units for bytes #265

oneup40 opened this issue Oct 2, 2017 · 9 comments

Comments

@oneup40
Copy link

oneup40 commented Oct 2, 2017

Package Versions

Replace the values below using the output from storjshare --version.

daemon: 5.1.0, core: 8.1.0, protocol: 1.2.0

Replace the values below using the output from node --version.

v6.11.3

Expected Behavior

When running "storjshare status", the CLI should either:

  1. Display the number of bytes stored in powers of 1000, using the SI abbreviations (KB, MB, GB, etc.)

  2. Display the number of bytes stored in powers of 1024, using the binary abbreviations (KiB, MiB, GiB, etc.)

Actual Behavior

"storjshare status" displays the number of bytes stored in powers of 1024, but uses the SI abbreviations (KB, MB, GB, etc.)

$ storjshare status
┌─────────────────────────────────────────────┬─────────┬──────────┬──────────┬─────────┬───────────────┬─────────┬──────────┬───────────┬──────────────┐
│ Share                                       │ Status  │ Uptime   │ Restarts │ Peers   │ Offers        │ Delta   │ Port     │ Shared    │ Bridges      │
├─────────────────────────────────────────────┼─────────┼──────────┼──────────┼─────────┼───────────────┼─────────┼──────────┼───────────┼──────────────┤
│ <redacted>                                  │ running │ <redact> │ 0        │ <redac> │ <redacted>    │ <redac> │ <redact> │ 3.24GB    │ connected    │
│   → node-1                                  │         │          │          │         │               │         │ <redact> │           │              │
└─────────────────────────────────────────────┴─────────┴──────────┴──────────┴─────────┴───────────────┴─────────┴──────────┴───────────┴──────────────┘

$ du -csb node-1/sharddata.kfs/
3495590390      node-1/sharddata.kfs/
3495590390      total
$ python2
Python 2.7.14 (default, Sep 20 2017, 01:25:59)
[GCC 7.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 3495590390 / 1000. / 1000. / 1000.
3.4955903900000003
>>> 3495590390 / 1024. / 1024. / 1024.
3.2555222418159246

As you can see, the number of bytes used is either approximately 3.50 GB or 3.26 GiB. storj appears to report the value in powers of 1024 but labels it with a power of 1000 unit, showing 3.24 GB.

Steps to Reproduce

Please include the steps the reproduce the issue, numbered below. Include as
much detail as possible.

  1. Run "storjshare status" to see how much data the node is reported as using.
  2. Run "du -csb /sharddata.kfs" to see how much the node is using.
  3. Divide the result from step 2 by 1000 repeatedly to see how many _B the node is using.
  4. Divide the result from step 2 by 1024 repeatedly to see how many _iB the node is using.
  5. Compare to the result from step 1 and see that the number from step 4 is used with the unit from step 3.
@braydonf
Copy link
Contributor

braydonf commented Oct 2, 2017

I don't think this number will be exact as it uses https://github.com/Level/leveldown#leveldown_approximateSize

@oneup40
Copy link
Author

oneup40 commented Oct 2, 2017

I understand it won't be exact to the number of bytes. But it seems to be using the wrong units, showing the number of GiB (gibibytes) but reporting it in GB (gigabytes). It's a small detail, but important for storage utilities to get correct.

The difference is using powers of 1000 vs. powers of 1024. If I had a node that currently had between 1000-1023 MB (megabytes) before going up to 1.0 GB, then that would be all the proof I need that it's using the wrong unit and should be showing MiB (mebibytes). But unfortunately all my nodes are currently above 1 GB and nowhere close to 1 TB.

I currently have 7 nodes:

Storjshare-daemon reported usage Real number of bytes reported by du -cs -B 1 Real number of GiB Real number of GB
7.11 GB 8120897536 7.56 GiB (+6.3%) 8.12 GB (+14.2%)
2.79 GB 3059036160 2.85 GiB (+2.2%) 3.06 GB (+9.6%)
4.15 GB 4580290560 4.27 GiB (+2.9%) 4.58 GB (+10.4%)
3.07 GB 3383595008 3.15 GiB (+2.6%) 3.38 GB (+10.1%)
1.85 GB 2075267072 1.93 GiB (+4.3%) 2.08 GB (+12.4%)
3.63 GB 3981864960 3.71 GiB (+2.2%) 3.98 GB (+9.6%)
5.11 GB 5536673792 5.16 GiB (+1.0%) 5.54 GB (+8.4%)

Average difference from real GiB: +3.1%
Average difference from real GB: +10.7%

See: https://en.wikipedia.org/wiki/Binary_prefix

@oneup40
Copy link
Author

oneup40 commented Oct 2, 2017

I've started a new node and I'm recording the output of "storjshare status" once per minute, so hopefully I'll catch it in that 1000-1023 MB telltale zone.

@littleskunk
Copy link
Collaborator

The problem is that we have to face windows user. GiB? Whats that? GB calculated in 1000? Why is the payout wrong, my drive full, the used space wrong? We would get a lot of issues (as we have seen in the early days). Yes 1024 GB is not correct but that way we have less problems with windows users.

image

@oneup40
Copy link
Author

oneup40 commented Oct 20, 2017

Are Windows users the primary target for storjshare daemon? Because right now you have the exact problem you listed with users of Linux and Mac OS X, which properly report sizes in the right units.

It seems from the various documentation though that Linux users are the primary audience.

@tempestb
Copy link

If I understand this, Oneup40 is not asking us to switch to 1,000 instead of 1,024. He is just concerned with the abbreviations being incorrect. I will change them to include the correct abbreviation and make a PR.

@Jurisg
Copy link

Jurisg commented Oct 23, 2017

Sector sizes on hard drive.
So more files more overhead on real size on hard disk.

@tempestb
Copy link

As Oneup40 noted in following the bytes() visionmedia/bytes.js#26 github issue on this topic, we appear to be at the mercy of this tool until either...

A) They introduce the bits() solutions
B) They change bytes() to support the binary standard

Until either of those happen, I guess we're unable to do anything about it right now. I suggest closing this issue and reopening it if any traction is made on the above.

@RichardLitt
Copy link

👋 Hey! Thanks for this contribution. Apologies for the delay in responding!

We've decided to rearchitect Storj, so that we can scale better. You can read more about this decision here. This means that we are entirely focused on v3 at the moment, in the storj/storj repository. Our white paper for v3 is coming very, very soon - follow along on the blog and in our Rocketchat.

As this repository is part of the v2 network, we're no longer maintaining this repository. I am going to close this for now. If you have any questions, I encourage you to jump on Rocketchat and ask them there. Thanks!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants