GC feature

[tarassh]

Periodic Garbage Collection

To enable the feature user has to pass a cmd parameter --enable-gc. Flag activates GC configuration settings stored ~/.ipfs/config

cat ~/.ipfs/config

...
"Datastore": {
    "StorageMax": "10GB",
    "GCPeriod": "1h",
    ...
}
...

StorageMax and GCPeriod are defaulted to 10GB and 1h respectively.

[rogarcia]

pls use the develop branch as base for new features so the PR gets merged there first

[sudeepdino008]

@tarassh given that we're removing the segments from the segments directory in bsp-agent, I think we should keep the ipfs maintained segments for a little longer, rather than just removing it after upload is done. The way to do this would be:

in ipfs-pinner:

• add GC related config to .ipfs/config file (https://blog.logrocket.com/guide-ipfs-garbage-collection/)
• check if the GC is indeed happening and the space is getting maintained via GC.

in bsp-agent:

• since ipfs-pinner is maintaining the segments for some time/storage space, we can cleanup the segments directory (or remove it entirely).

[sudeepdino008]

@tarassh

• document the config parameters needed in the README.
• Also change the dockerfile to have --enable-gc.
• what happens when gc config parameters are not there? GC doesn't happen? If it doesn't, then it might be useful to have a warning message, something like: "gc is enabled; but parameters not available in config; GC won't run"

[tarassh]

@sudeepdino008

what happens when gc config parameters are not there? GC doesn't happen? If it doesn't, then it might be useful to have a warning message, something like: "gc is enabled; but parameters not available in config; GC won't run"

Default values will be used even if config file does not exist.