ipfs block rm

[daviddias]

Currently, the only way of deleting blocks in go-ipfs is through repo gc. In js-ipfs land, since the Block Service exposes an interface to delete, we also have exposed that on the block API. It is very convenient for testing and a quick way to delete a specific block.

Can we expose this feature in go-ipfs too?

[Kubuxu]

Is should be really easy as we also have Delete call in blockstore. Problem with deleting block is that it might be component of different file or directory and as user would probably expect the removal of all blocks connected to file or directory it is even bigger issues.

[daviddias]

@Kubuxu that would be something for the files api. The block API is really well scoped as the put and get only also return or add a single block

[Kubuxu]

Ahh, right. So yeah, ipfs block rm should be possible and quite easy to do.

[kevina]

How should removing pinned blocks be handled? Disallow? Allow and ignore pin? (This could then cause many problems with ipfs commands, for example the garbage collector will abort) Allow and attempt to do something about the pin? (Not so easy unless the pin a a direct pin.)

[whyrusleeping]

Yeah, we need to make sure we don't remove blocks that are pinned.

[daviddias]

Good point. If a block is pinned, it should error saying that it is pinned

[kevina]

I agree at least by default. However, for performance reasons, we might want to add an option to disable this detection if the user knows what they are doing.

I am not 100% sure I understand the pining code but it seams that to detect indirect pins all recursive pins need to be walked, thus making pin detection expensive. It looks like there might be some caching going on in the datastore under the prefix 'local/pins/indirect/keys/' but it doesn't seam like this is used by pin.IsPinnedWithType().

[whyrusleeping]

Yeah, pin detection is expensive. We can optimize with various caching structures though in the future.

[kevina]

I know the issues involved so I take responsibility for this one.

[RichardLitt]

Participating.

[daviddias]

Any update on this one? :)

[kevina]

@diasdavid please see #2962

[whyrusleeping]

we have this now :)

[daviddias]

woot!