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

IPFS should stop accepting pin requests/new files after hitting the StorageMax limit #7875

Closed
RubenKelevra opened this issue Jan 21, 2021 · 2 comments
Labels
kind/enhancement A net-new feature or improvement to an existing feature status/duplicate This issue or pull request already exists

Comments

@RubenKelevra
Copy link
Contributor

RubenKelevra commented Jan 21, 2021

IPFS will currently accept pins and new files for the MFS when way beyond StorageMax. This is an issue since there's no other measure in place to stop writing more data to the disk than that.

When the GC is on it cannot clean up when we just continue pinning stuff, since it's not allowed to clean pins up.

While changing StorageMax to a hard limit for pinning/mfs operation, it should affect any other operations like getting data from the network or DHT operations, so the node continues to be operational - it just cannot mark more data for storing it permanently.

An example:

$ ipfs repo stat
NumObjects: 404282
RepoSize:   88709351300
StorageMax: 60000000000
RepoPath:   /home/ipfs/.ipfs
Version:    fs-repo@11
$ du -hc .ipfs/blocks/ | grep total
83G     total

IPFS is started on this machine with --enable-gc on.

This is somewhat related to this: #3066

@RubenKelevra RubenKelevra added the kind/enhancement A net-new feature or improvement to an existing feature label Jan 21, 2021
@RubenKelevra
Copy link
Contributor Author

RubenKelevra commented Jan 21, 2021

This is basically how StorageMax was originally intended to work (I guess):

https://github.com/ipfs/go-ipfs/blob/master/test/sharness/t0082-repo-gc-auto.sh#L57

@gammazero gammazero added the need/triage Needs initial labeling and prioritization label Jan 21, 2021
@Stebalien
Copy link
Member

Stebalien commented Feb 12, 2021

Duplicate of #5140.

@Stebalien Stebalien added status/duplicate This issue or pull request already exists and removed need/triage Needs initial labeling and prioritization labels Feb 12, 2021
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 status/duplicate This issue or pull request already exists
Projects
None yet
Development

No branches or pull requests

3 participants