# Release preparation v1.108

**URL:** <https://forum.storj.io/t/release-preparation-v1-108/27006>\
**Category:** STORJLINGS\
**Created:** [July 8, 2024, 5:36pm UTC](https://forum.storj.io/t/release-preparation-v1-108/27006 "2024-07-08T17:36:33Z")\
**Posts on this page:** 4\
**Page:** 6

<div class="post-metadata">

**Author:** ![arrogantrabbit](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/arrogantrabbit/32/11200_2.png) [@arrogantrabbit](https://forum.storj.io/u/arrogantrabbit)\
**Post date:** [July 29, 2024, 3:23am UTC](https://forum.storj.io/t/release-preparation-v1-108/27006/102 "2024-07-29T03:23:43Z")

</div>

> [@Ambifacient](#):
>
> > [@agente](#):
> >
> > wow. mind blowing… do you tried it for long time? is it safe?
> 
> I do this on ZFS using quotas and it works fine.

Can confirm. I’ve set refquota on a dataset that is used for storage, but not on the one used for databases. Then I set available space to 999TB in the config file. Egress stops correctly, when whatever buffer, (5GB?) of free space is remaining, regardless of what node thinks it’s supposed to be using. Dashboard shows total space correctly, matching the quota.

It’s a brilliant solution that guarantees the node won’t be able to overshoot the allocated space.

This also makes it easy to adjust space. I don’t need to restart the node.

---

<div class="post-metadata">

**Author:** ![Toyoo](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/toyoo/32/1126_2.png) [@Toyoo](https://forum.storj.io/u/Toyoo)\
**Post date:** [July 29, 2024, 3:32am UTC](https://forum.storj.io/t/release-preparation-v1-108/27006/103 "2024-07-29T03:32:48Z")

</div>

This is still a bit scary if anything else is on the same file system or within the same quota, like logs, databases or order files. Even if a node is technically not accepting uploads, these other files may fill up the rest of the quota. Then node would start failing downloads or even simple bandwidth rollups.

---

<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:** [August 3, 2024, 3:58pm UTC](https://forum.storj.io/t/release-preparation-v1-108/27006/104 "2024-08-03T15:58:11Z")

</div>

> [@elek](#):
>
> And thanks for the report. I will try to reproduce it…

It turns out, the Raspberry pi I was testing badger on is still running an older 32 bit version of Raspbian OS. The node was created back in 2019. I suspect that might be why I received the “mremap size mismatch” error when testing the new badger cache. I see that a 32bit OS is not within the current published system requirements. I will need to reinstall the OS at some point.

---

<div class="post-metadata">

**Author:** ![arrogantrabbit](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/arrogantrabbit/32/11200_2.png) [@arrogantrabbit](https://forum.storj.io/u/arrogantrabbit)\
**Post date:** [August 3, 2024, 4:39pm UTC](https://forum.storj.io/t/release-preparation-v1-108/27006/105 "2024-08-03T16:39:34Z")

</div>

Then it’s a bug that needs to be fixed. Storj does offer 32bit binaries, there are plenty of 32 bit systems around.

It’s possible it’s badger bug who also neglects 32 bit systems. Then the feature needs to be disabled on 32 bit systems.

The real problem is I don’t things storj _tests_ 32 bit binaries they produce in the first place ( I have reported 32-bit system related bug in the past too, and both bugs reproduce immediately). That too needs to be fixed.

[Previous page](https://forum.storj.io/t/release-preparation-v1-108/27006.md?page=5)