Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DiskUsage and approximate values #85

Open
hsanjuan opened this issue Mar 9, 2018 · 0 comments
Open

DiskUsage and approximate values #85

hsanjuan opened this issue Mar 9, 2018 · 0 comments
Labels
kind/enhancement A net-new feature or improvement to an existing feature

Comments

@hsanjuan
Copy link
Contributor

hsanjuan commented Mar 9, 2018

Per ipfs/go-ds-flatfs#27, @kevina and others have raised concerns about not being possible to identify that the values returned by DiskUsage() might be approximate. It is also not possible to correct this programatically. Interesting bits:

I think it would be better to to keep track of if the disk usage is an estimate or an accurate count and inform the user of which

Then it that case I think a better solution is to return an undefined value for the DiskUsage possible informing the user on how to rectify it for large repos rather than return an estimate that can be 5-10% off without informing the user of the inaccuracy.

This information should at least be stored in the datastore somehow. Providing an interface to get to determine if the value stored is an approximation or an exact value can be a separate p.r.

Regarding re-calculating size:

Check from CheckedDatastore is meant to be triggered on ipfs repo fsck. I'm not sure where Scrub should get invoked, probably separate command like ipfs repo scrub.

ScrubbedDatastore.Scrub is probably where we want to wire this into. (Check / repo fsck should be fast).

This issue is to discuss the best approach to exposing that are innacurate.

Note that badger only updates the Size() once a minute. flatfs may have estimated the size during first launch and this might be off from the real size on big repositories or very slow disk. It also doesn't account for the growth of the directory sizes as the datastore gets filled with data.

@hsanjuan hsanjuan added the kind/enhancement A net-new feature or improvement to an existing feature label Mar 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement A net-new feature or improvement to an existing feature
Projects
None yet
Development

No branches or pull requests

1 participant