# Badger cache: are we ready?

**URL:** <https://forum.storj.io/t/badger-cache-are-we-ready/27323>\
**Category:** Node Operators\
**Tags:** badger\
**Created:** [July 28, 2024, 9:41am UTC](https://forum.storj.io/t/badger-cache-are-we-ready/27323 "2024-07-28T09:41:48Z")\
**Posts on this page:** 20\
**Page:** 8

<div class="post-metadata">

**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\
**Post date:** [September 22, 2024, 4:13am UTC](https://forum.storj.io/t/badger-cache-are-we-ready/27323/141 "2024-09-22T04:13:20Z")

</div>

I reported this problem to the team, I didn’t see such a error for audits.  
Where is this cache located?

> [@Mark](#):
>
> We might have to split the thread though for this topic.

I’m agree. So for the further readers - please use a “Reply” button here and change to answer as a separate topic.

---

<div class="post-metadata">

**Author:** ![JWvdV](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/jwvdv/32/7814_2.png) [@JWvdV](https://forum.storj.io/u/JWvdV)\
**Post date:** [September 22, 2024, 7:34am UTC](https://forum.storj.io/t/badger-cache-are-we-ready/27323/142 "2024-09-22T07:34:02Z")

</div>

> [@Mark](#):
>
> I think it all happened fairly quickly.

Meaning, you already had a low online score. Something that probably hasn’t to do with the badger cache at all.

> [@Mark](#):
>
> I’m having trouble finding a N100 mini PC for under $100 USD. A pi 5(with 8GB Ram) is about $80, maybe $92 after the power supply, but with no case.

Exactly, and you still forgot the micro-SD or any other storage. I bought some time ago a N100 with 16G RAM, 512G SSD for about $120. That’s much more performance, for a penny more so to say. I would recommend AliExpress for it.

RPi’s were really great for many projects in the beginning, but in mean time I switched them all to mini-PCs for different reasons.

---

<div class="post-metadata">

**Author:** ![snorkel](https://storj.bcdn.literatehosting.com/letter_avatar/snorkel/32/5_5575768a8748004e209b776fc1b2916d.png) [@snorkel](https://forum.storj.io/u/snorkel)\
**Post date:** [September 22, 2024, 10:31am UTC](https://forum.storj.io/t/badger-cache-are-we-ready/27323/143 "2024-09-22T10:31:32Z")

</div>

Maybe you can find some tips here:

[https://forum.storj.io/t/new-storagenode-build-intel-n100/24861?u=snorkel](https://forum.storj.io/t/new-storagenode-build-intel-n100/24861)

The N100 with 32GB RAM is overkill for storagenodes. You can find NAS type cases from many brands.  
If you go building something new for Storj, take note that you need as much RAM as you can and SATA ports. These 2 are the main requirements. The third would be power draw.

---

<div class="post-metadata">

**Author:** ![Mark](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/mark/32/1128_2.png) [@Mark](https://forum.storj.io/u/Mark)\
**Post date:** [September 23, 2024, 8:11am UTC](https://forum.storj.io/t/badger-cache-are-we-ready/27323/144 "2024-09-23T08:11:57Z")

</div>

> [@Alexey](#):
>
> Where is this cache located?

Default location in the storage folder on a spinning disk. This drive has had bad sectors reallocated in the past. Maybe the cache is corrupted? Perhaps I’ll move the cache to another disk.

---

<div class="post-metadata">

**Author:** ![ifraixedes](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/ifraixedes/32/71_2.png) [@ifraixedes](https://forum.storj.io/u/ifraixedes)\
**Post date:** [September 23, 2024, 9:08am UTC](https://forum.storj.io/t/badger-cache-are-we-ready/27323/145 "2024-09-23T09:08:20Z")

</div>

If you can, we should discard first that does not cause that.

Thank you for all the digging and reporting.

---

<div class="post-metadata">

**Author:** ![baliqci](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/baliqci/32/6544_2.png) [@baliqci](https://forum.storj.io/u/baliqci)\
**Post date:** [November 28, 2024, 10:22pm UTC](https://forum.storj.io/t/badger-cache-are-we-ready/27323/146 "2024-11-28T22:22:21Z")

</div>

If this cache is enabled, will the disk load decrease when the garbage collector is running?

---

<div class="post-metadata">

**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\
**Post date:** [November 29, 2024, 4:57am UTC](https://forum.storj.io/t/badger-cache-are-we-ready/27323/147 "2024-11-29T04:57:20Z")

</div>

Hello @baliqci,  
Welcome back!

Depends on your setup, but it might be, except the first scan.

---

<div class="post-metadata">

**Author:** ![EasyRhino](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/easyrhino/32/1133_2.png) [@EasyRhino](https://forum.storj.io/u/EasyRhino)\
**Post date:** [December 3, 2024, 9:08pm UTC](https://forum.storj.io/t/badger-cache-are-we-ready/27323/148 "2024-12-03T21:08:26Z")

</div>

> [@baliqci](#):
>
> If this cache is enabled, will the disk load decrease when the garbage collector is running?

I noticed increased disk loan when using the used space filewalker. garbage collection… maybe higher but not dramatically higher?

---

<div class="post-metadata">

**Author:** ![snorkel](https://storj.bcdn.literatehosting.com/letter_avatar/snorkel/32/5_5575768a8748004e209b776fc1b2916d.png) [@snorkel](https://forum.storj.io/u/snorkel)\
**Post date:** [December 6, 2024, 6:33am UTC](https://forum.storj.io/t/badger-cache-are-we-ready/27323/149 "2024-12-06T06:33:10Z")

</div>

I took a closer look at my logs and see that the retain process takes 7h each time it runs for 4TB node on 32GB RAM Ubuntu machine; it’s like the startup filewalker runs each time retain runs… which makes sense, because in order to move the pieces to trash, it needs to check all the pieces against the bloom filter.  
I was thinking of enabling the badger, too.  
I get that the badger cache will be dropped once the new hashstore is fully implemented?  
So, we should not bother with activating the badger anymore?

---

<div class="post-metadata">

**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\
**Post date:** [December 6, 2024, 8:17am UTC](https://forum.storj.io/t/badger-cache-are-we-ready/27323/150 "2024-12-06T08:17:59Z")

</div>

It wouldn’t be dropped, but the result would not change so significantly for hashstore as for the default piecestore. There is still a benefit even for the hashstore backend, but around a measure error.  
And there is no plans to make a hashstore the default backend, you must it enable separately, see:

> [@\[Tech Preview\] Hashtore backend for storage nodes](https://forum.storj.io/t/tech-preview-hashtore-backend-for-storage-nodes/28724):
>
> Do you remember that one big customer we simulated on SLC? If not here is a short recap. That customer uploads a high amount of small and medium size files with a short TTL. It turns out storage nodes can handle the initial uploads but things gets expensive when the TTL kicks in. The storage nodes simply needs too much time deleting such an high amount of pieces. The solution for that problem is the new hashstore backend. Instead of storing all pieces as a file on disk the hashstore backend com…

---

<div class="post-metadata">

**Author:** ![javierxam](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/javierxam/32/7816_2.png) [@javierxam](https://forum.storj.io/u/javierxam)\
**Post date:** [December 17, 2024, 4:29pm UTC](https://forum.storj.io/t/badger-cache-are-we-ready/27323/151 "2024-12-17T16:29:41Z")

</div>

What happens with this cache? it’s secure to enable finally?

---

<div class="post-metadata">

**Author:** ![snorkel](https://storj.bcdn.literatehosting.com/letter_avatar/snorkel/32/5_5575768a8748004e209b776fc1b2916d.png) [@snorkel](https://forum.storj.io/u/snorkel)\
**Post date:** [December 17, 2024, 4:38pm UTC](https://forum.storj.io/t/badger-cache-are-we-ready/27323/152 "2024-12-17T16:38:56Z")

</div>

You have your answear just above your post…

---

<div class="post-metadata">

**Author:** ![Roberto](https://storj.bcdn.literatehosting.com/letter_avatar/roberto/32/5_5575768a8748004e209b776fc1b2916d.png) [@Roberto](https://forum.storj.io/u/Roberto)\
**Post date:** [December 26, 2024, 4:48pm UTC](https://forum.storj.io/t/badger-cache-are-we-ready/27323/153 "2024-12-26T16:48:30Z")

</div>

Hi, lately I have this error when I try to find the api key for Multinode Dashboard

```auto
# docker exec -it storagenode /app/bin/storagenode issue-apikey --config-dir /app/config --identity-dir /app/identity
2024-12-26T16:40:26Z INFO Configuration loaded {"Process": "storagenode", "Location": "/app/config/config.yaml"}
2024-12-26T16:40:27Z INFO Anonymized tracing enabled {"Process": "storagenode"}
2024-12-26T16:40:27Z INFO Identity loaded. {"Process": "storagenode", "Node ID": "1Kf6y9Mxxxxxxxxxxxxxxxxxxxxxxxxx"}
Error: Error starting master database on storage node: Cannot acquire directory lock on "/app/config/storage/filestatcache". Another process is using this Badger database. error: resource temporarily unavailable

```

It seems like a Badger cache error. What do you recommend?

---

<div class="post-metadata">

**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\
**Post date:** [December 27, 2024, 5:41am UTC](https://forum.storj.io/t/badger-cache-are-we-ready/27323/155 "2024-12-27T05:41:51Z")

</div>

You need to disable a badger cache when you invoke the second instance:

```auto
# docker exec -it storagenode /app/bin/storagenode issue-apikey --config-dir /app/config --identity-dir /app/identity --pieces.file-stat-cache=""

```

See

> [@Badger cache: are we ready?](https://forum.storj.io/t/badger-cache-are-we-ready/27323/82):
>
> This need to be investigated. I wouldn’t expect it to be corrupted due to a normal restart. By the way, I accidentally found a solution for the docker node when the badger cache is enabled: you shouldn’t enable the badger cache in the config.yaml file, you need to use a command line option after the image name, so when you exec the key issue command in the docker container, it didn’t try to lock a filecache, because it’s not enabled in the config. This also explains why it works for my Doc…

---

<div class="post-metadata">

**Author:** ![snorkel](https://storj.bcdn.literatehosting.com/letter_avatar/snorkel/32/5_5575768a8748004e209b776fc1b2916d.png) [@snorkel](https://forum.storj.io/u/snorkel)\
**Post date:** [January 15, 2025, 5:04am UTC](https://forum.storj.io/t/badger-cache-are-we-ready/27323/156 "2025-01-15T05:04:39Z")

</div>

In theory, if I have badger cache enabled and decide to switch it off by removing the parameter in the run command, turn also startup piecescan off, but not deleting badger’s directory, what happens when I enable badger again after some time?  
It would see old and wrong data, so the badger dir must be deleted first, than badger reenabled?

---

<div class="post-metadata">

**Author:** ![Mark](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/mark/32/1128_2.png) [@Mark](https://forum.storj.io/u/Mark)\
**Post date:** [January 16, 2025, 12:54pm UTC](https://forum.storj.io/t/badger-cache-are-we-ready/27323/157 "2025-01-16T12:54:53Z")

</div>

I could be mistaken but I believe the old badger cache would be incomplete but not wrong. When the node needs data about a stored file, it checks the cache first. If the data is not in the cache the node will get it from the file system instead.

---

<div class="post-metadata">

**Author:** ![daniel1](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/daniel1/32/1122_2.png) [@daniel1](https://forum.storj.io/u/daniel1)\
**Post date:** [January 17, 2025, 2:23pm UTC](https://forum.storj.io/t/badger-cache-are-we-ready/27323/158 "2025-01-17T14:23:48Z")

</div>

For testing purposes, i enabled badger cache, and the whole disk feature on my node, and now the dashboard shows it’s offline. UPTIME 0m, VERSION v, and blank node id. Is this normal ? Besides that it seems to operate normally, im getting traffic, and the logs only contains a few ERROR piecestore upload failed EOF.

---

<div class="post-metadata">

**Author:** ![Vadim](https://storj.bcdn.literatehosting.com/letter_avatar/vadim/32/5_5575768a8748004e209b776fc1b2916d.png) [@Vadim](https://forum.storj.io/u/Vadim)\
**Post date:** [January 17, 2025, 6:05pm UTC](https://forum.storj.io/t/badger-cache-are-we-ready/27323/159 "2025-01-17T18:05:44Z")

</div>

1.120 relised and updating nodes, this is the END of badger cache.

---

<div class="post-metadata">

**Author:** ![Roberto](https://storj.bcdn.literatehosting.com/letter_avatar/roberto/32/5_5575768a8748004e209b776fc1b2916d.png) [@Roberto](https://forum.storj.io/u/Roberto)\
**Post date:** [January 17, 2025, 6:29pm UTC](https://forum.storj.io/t/badger-cache-are-we-ready/27323/160 "2025-01-17T18:29:31Z")

</div>

Why? For those who use piecestore it will no longer be necessary?  
While the work on hashstore is impressive, it doesn’t seem as robust as piecestore

---

<div class="post-metadata">

**Author:** ![snorkel](https://storj.bcdn.literatehosting.com/letter_avatar/snorkel/32/5_5575768a8748004e209b776fc1b2916d.png) [@snorkel](https://forum.storj.io/u/snorkel)\
**Post date:** [January 17, 2025, 8:22pm UTC](https://forum.storj.io/t/badger-cache-are-we-ready/27323/161 "2025-01-17T20:22:43Z")

</div>

I activated badger cache on all nodes and I will stay away from hashstore untill it matures a little bit more. I estimate 6 months would be enough to make it optimal. Untill than, piecestore it’s reliable and with the help of badger cache, it’s fast enough.

[Previous page](https://forum.storj.io/t/badger-cache-are-we-ready/27323.md?page=7)

[Next page](https://forum.storj.io/t/badger-cache-are-we-ready/27323.md?page=9)
