blockstore: add GarbageCollect method to GCBlockstore interface

[iand]

This is a short proposal to extend the GCBlockstore interface to add a method for performing garbage collection on the store. This is motivated by this issue which aims to enable alternate garbage collection algorithms to be used in go-ipfs.

I propose to add a single method GarbageCollect with the following signature

GarbageCollect(ctx context.Context, keep *cid.Set, goal int64, results chan<- GCResult)

When called the blockstore should attempt to remove unneeded or low value blocks in order to reclaim space. Since GC may be time consuming this method uses a channel to report progress and is intended to be run asynchronously.

The keep argument specified a set of CIDs of blocks that must be retained. The goal argument is a hint to the blockstore for the amount of space that should be freed. It is informative not prescriptive. The blockstore should attempt to free at least this amount of space and may free more. The method should return information about each block removed or errors encountered using the results argument.

GCResult is a struct that may hold information about a block that was removed or an error that was encountered while doing so

type GCResult struct {
	KeyRemoved cid.Cid
	Error      error
}

Note that this interface change is a breaking change, however almost all applications that use GCBlockstore use the in-built implementation created using NewGCBlockstore and this can be adjusted to return a type that satisfies the modified interface . An alternate approach is to create a new interface that embeds GCBlockstore and the new method.

I have created an implementation of the proposed change: https://github.com/ipfs/go-ipfs-blockstore/pull/104

[welcome[bot]]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review. In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment. Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

[RubenKelevra]

NewGCBlockstore

New/old terminology is usually pretty bad in the future. How will the next new function be called? Newnew? ;)

[iand]

NewGCBlockstore

New/old terminology is usually pretty bad in the future. How will the next new function be called? Newnew? ;)

What do you mean? That is the convention for naming Go constructors and already exists in this package.

[RubenKelevra]

Ah, nevermind. :)