# Prevent GC when adding large file

**URL:** <https://discuss.ipfs.tech/t/prevent-gc-when-adding-large-file/13694>\
**Category:** IPFS Cluster\
**Tags:** go-ipfs, ipfs-cluster, files\
**Created:** [March 9, 2022, 11:24am UTC](https://discuss.ipfs.tech/t/prevent-gc-when-adding-large-file/13694 "2022-03-09T11:24:38Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![tiago](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/tiago/32/5654_2.png) [@tiago](https://discuss.ipfs.tech/u/tiago)\
**Post date:** [March 9, 2022, 11:24am UTC](https://discuss.ipfs.tech/t/prevent-gc-when-adding-large-file/13694/1 "2022-03-09T11:24:38Z")

</div>

When using the IPFS Cluster REST API to add a large file, one has to prevent Garbage Collection of that file.

From [this page](https://cluster.ipfs.io/documentation/guides/pinning/#adding-files) and the IPFS Cluster REST API one, I’d say we should use “local=true” and “allocations=true” query parameter (from --allocations flag (not sure this one really exists)) to force the pin to be allocated to the same peer ID on which it is being added.

Is that so?

---

<div class="post-metadata">

**Author:** ![Jorropo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/jorropo/32/3230_2.png) [@Jorropo](https://discuss.ipfs.tech/u/Jorropo)\
**Post date:** [March 9, 2022, 3:11pm UTC](https://discuss.ipfs.tech/t/prevent-gc-when-adding-large-file/13694/2 "2022-03-09T15:11:20Z")

</div>

> [@tiago](#):
>
> When using the IPFS Cluster REST API to add a large file, one has to prevent Garbage Collection of that file.

Why ? IPFS-Cluster does that for you:

```console
$ ipfsc add main.go 
added QmVk8b4UCxTFfmL3Dj4yRmUKnRK7Ykj46Qs2TQWXRnnjcK main.go
$ ipfsc pin ls | grep QmVk8b4UCxTFfmL3Dj4yRmUKnRK7Ykj46Qs2TQWXRnnjcK
QmVk8b4UCxTFfmL3Dj4yRmUKnRK7Ykj46Qs2TQWXRnnjcK | | PIN | Repl. Factor: -1 | Allocations: [everywhere] | Recursive | Metadata: no | Exp: ∞ | Added: 2022-03-09 16:09:45

```

---

<div class="post-metadata">

**Author:** ![Jorropo](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/jorropo/32/3230_2.png) [@Jorropo](https://discuss.ipfs.tech/u/Jorropo)\
**Post date:** [March 9, 2022, 3:13pm UTC](https://discuss.ipfs.tech/t/prevent-gc-when-adding-large-file/13694/3 "2022-03-09T15:13:34Z")

</div>

NVM I have seen your other post.

The best solution is to NOT run the `--enable-gc` (note GC is opt in with `ipfs daemon --enable-gc`).  
And run `ipfs-cluster-ctl repo gc` from time to time when you know you are safe.

---

<div class="post-metadata">

**Author:** ![tiago](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/tiago/32/5654_2.png) [@tiago](https://discuss.ipfs.tech/u/tiago)\
**Post date:** [March 9, 2022, 3:18pm UTC](https://discuss.ipfs.tech/t/prevent-gc-when-adding-large-file/13694/4 "2022-03-09T15:18:50Z")

</div>

According to [Adding and pinning - Pinset orchestration for IPFS](https://cluster.ipfs.io/documentation/guides/pinning/#adding-files)

> Adding with --local with positive replication-factors may mean that the content is added on a peer that is finally not allocated to store the content and will not end up pinning it. Sometimes, when this is relevant, it can be worked around using the --allocations flag to force the pin to be allocated to the same peer ID on which it is being added.

---

<div class="post-metadata">

**Author:** ![hector](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.ipfs.tech/hector/32/178_2.png) [@hector](https://discuss.ipfs.tech/u/hector)\
**Post date:** [March 9, 2022, 4:33pm UTC](https://discuss.ipfs.tech/t/prevent-gc-when-adding-large-file/13694/5 "2022-03-09T16:33:35Z")

</div>

Hello,

that piece of documentation is wrong as the behavior changed in the last release. Adding with local=true will result in the local peer being part of the allocations now. I have updated the documentation.

Also, allocations work like `?allocations=<peerid1>,<peerid2>` (not true).

All that said, that does not necessarily prevent any GCing, it does potentially leave less things to be GC’ed behind (as the blocks will be added to a peer that becomes a pinner afterwards).