# Обновление информации о оставшемся свободном пространстве и другие баги связанные со свободным местом, которые никогда не исправят

**URL:** <https://forum.storj.io/t/topic/25649>\
**Category:** troubleshooting\
**Tags:** storage, на-русском, web-dashboard\
**Created:** [March 28, 2024, 8:28am UTC](https://forum.storj.io/t/topic/25649 "2024-03-28T08:28:38Z")\
**Posts on this page:** 12\
**Page:** 3

<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:** [April 2, 2024, 7:53am UTC](https://forum.storj.io/t/topic/25649/41 "2024-04-02T07:53:26Z")

</div>

Спасибо за возвращение меня в ряды людей.

> [@d4rk4](#):
>
> Не смотря на то что указан лимит свободного места в 5Тб в конфиге нод, я вижу риски, что данные стораджа займут все **свободное пространство** и ноды упадут и я не смогу их перезапустить, пока не добавлю свободного места.

они не должны упасть, там захардкожен предохранитель, если останется около 500МБ в выделении или на диске - узел уведомит сателлиты, что он полный и будет отклонять попытки загрузить на него что-то.  
Однако то, что у вас данные в БД разошлись с данными с диска - не здорово. Видимо `used-space-filewalker` у вас занимает неприлично долгое время. Я бы рекомендовал отключить lazy mode и ни в коем случае не отключать `used-space-filewalker` на старте. Если есть возможность - добавьте SSD as a special device, другие пользователи zfs утверждают, что это решает все проблемы.  
Вызов

> [@d4rk4](#):
>
> statfs()

не поможет, нам надо знать сколько осталось в выделении, а не на диске. Хотя последнее тоже проверяется (на старте, чтобы выбрать минимальное из выделения и сколько есть на самом деле; и потом, при каждой загрузке, чтобы понять пора дёргать стоп-кран или ещё нет).  
И да, узел использует СИ (десятичные единицы измерения), а вы запрашиваете бинарные.  
Запросите так:

```auto
df --si -T

```

---

<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:** [April 2, 2024, 7:58am UTC](https://forum.storj.io/t/topic/25649/42 "2024-04-02T07:58:54Z")

</div>

Что имеет ввиду @andylevi16, так это то, что мы рекомендуем оставлять 10% свободного места, то есть не выделять всё под крышечку. Если мы вдруг выпустим версию с багом - узел может теоретически скушать всё настолько, что ему в базу запись добавить не удастся (и он её с вероятностью 99% убъёт постоянными попытками), и после этого узел даже запустить не получится.  
Но не будем о кошмарах. Желательно иметь свободное место на диске на непредвиденный случай, резко освободить его будет тяжело, даже удаление `trash` может привести к дисквалификации, если сателлит запросит восстановить оттуда данные и попробует их проверить.

Возможно 10% это много, особенно для больших узлов. Но иметь свободными хотя бы 200ГБ я бы порекомендовал (видел на одном из своих узлов overusage 100GB…).

---

<div class="post-metadata">

**Author:** ![d4rk4](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/d4rk4/32/68_2.png) [@d4rk4](https://forum.storj.io/u/d4rk4)\
**Post date:** [April 2, 2024, 9:08am UTC](https://forum.storj.io/t/topic/25649/43 "2024-04-02T09:08:03Z")

</div>

> [@Alexey](#):
>
> они не должны упасть, там захардкожен предохранитель, если останется около 500МБ в выделении или на диске - узел уведомит сателлиты, что он полный и будет отклонять попытки загрузить на него что-то.

Это не работает по факту, я уже с этим сталкивался.

> [@Alexey](#):
>
> Однако то, что у вас данные в БД разошлись с данными с диска - не здорово. Видимо `used-space-filewalker` у вас занимает неприлично долгое время.

Смотрите мой пост выше с логами, 5 минут занимает

**И главный вопрос как правильно задать порог минимального свободного места, после которого нода перестает принимать новые данные?**

---

<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:** [April 7, 2024, 8:01am UTC](https://forum.storj.io/t/topic/25649/44 "2024-04-07T08:01:16Z")

</div>

> [@d4rk4](#):
>
> Это не работает по факту, я уже с этим сталкивался.

Не могли бы вы эти факты предоставить? Предохранитель был сделан давно

> [@Changelog v1.9.5](https://forum.storj.io/t/changelog-v1-9-5/8335/1):
>
> **Free Space Fix**  
> Storage nodes are executing the used space calculation only once on startup. From there the storage node is keeping and updating used space and free space in memory. The storage node should notify the satellite below 500MB free space. This free space value can get outdated and for that reason, we added a second free space check a few releases ago. This second free space check gets executed on every upload but it didn’t notify the satellite. With this release, we are combining both free space checks to make sure the satellite stops selecting full storage nodes.

Пока что это работает для всех тысяч узлов, кроме почему-то вашего. Это нужно исследовать. Если мы допустили баг здесь, его необходимо срочно исправить.  
Опишите подробно, как вы добились, чтобы узел использовал диск без остатка?

> [@d4rk4](#):
>
> И главный вопрос как правильно задать порог минимального свободного места, после которого нода перестает принимать новые данные?

Оно не задаётся, оно вычисляется: сколько осталось места в выделении (выделенное минус использованное по данным узла).  
Мы рекомендуем оставлять 10% от полной вместимости, однако если вы любите риск, вы можете выделить почти всё, но я бы рекомендовал оставлять свободными хотя бы 100ГБ-200ГБ.

Аварийный уровень захардкожен на 500МБ (см. заметки о выпуске выше) и проверяется при каждой попытке загрузить кусочек на ваш узел.  
Это может не сработать, если вы растащили папку `storage` по дискам/папкам симлинками или с помощью mount в docker.  
Но для надёжности мы рекомендуем выделять место для узла на 10% меньше полной вместимости диска.

---

<div class="post-metadata">

**Author:** ![d4rk4](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/d4rk4/32/68_2.png) [@d4rk4](https://forum.storj.io/u/d4rk4)\
**Post date:** [April 7, 2024, 8:23am UTC](https://forum.storj.io/t/topic/25649/45 "2024-04-07T08:23:11Z")

</div>

> [@Alexey](#):
>
> Не могли бы вы эти факты предоставить? Предохранитель был сделан давно

В каком виде предоставить? Смысл в том, что если несколько нод шарят дисковое пространство, то видимо нода не успевает включить этот киллсвитч. Плюс у меня есть тестовая нода, которая на отдельной железке с аппаратным рейдом на ZeusIOPS, так на ней я периодически наблюдаю, что свободное дисковое пространство опускается до 400-450 Мб. Вот кстати ситуация прямо сейчас на _12RYDKnKqrByfHDrx3ACxe3w1THnJ8txN765qTWeYFdFV5YqSBu_:

```auto
root@cg1:~# df -h | grep storj
/dev/mapper/pool-storj--orders 7.4G 907M 6.6G 12% /opt/storj/orders
/dev/mapper/pool-storj--data 2.2T 2.2T 449M 100% /opt/storj/data
/dev/mapper/pool-storj--id 888M 39M 850M 5% /opt/storj/id
/dev/mapper/pool-storj--db 7.4G 268M 7.2G 4% /opt/storj/db

```

> [@Alexey](#):
>
> Аварийный уровень захардкожен на 500МБ (см. заметки о выпуске выше) и проверяется при каждой попытке загрузить кусочек на ваш узел.

Ну как мы видим по какой-то причине это не срабатывает (мне кажется, из-за того, что одновременно несколько аплоадов работает, например при кейсе 10 клиентов загружают чанки по 64мб, тогда киллсвитч тупо не успеет отработать) + хотелось бы иметь отдельную настройку, вместо хардкода. Это полезно для кейсов, где несколько нод или другого софта шарят одно дисковое пространство (большие ZFS пулы например как у меня, или ваш любимый концепт реюза свободного места с инфраструктуры которую уже использует другой сервис)

---

<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:** [April 7, 2024, 8:37am UTC](https://forum.storj.io/t/topic/25649/46 "2024-04-07T08:37:47Z")

</div>

> [@d4rk4](#):
>
> В каком виде предоставить? Смысл в том, что если несколько нод шарят дисковое пространство

Именно это запрещено делать по условиям [Node Operator Terms & Conditions](https://www.storj.io/node-operator-terms-conditions)  
Вы решили нарушить - получайте предсказуемый результат. Правила обычно написаны “кровью”.  
Вы не должны запускать более одного узла на диск (пул - это один диск для системы).  
Это просто бессмысленно, все узлы в одной подсети /24 получат тот же объём трафика, что и один узел. Запускать несколько имеет смысл в таком случае только чтобы как раз не возиться с RAID. У вас будет один узел на один диск. Умрёт диск, вы потеряете только 1/х общих данных вашей подсети. Это намного лучше, чем потерять всё из-за RAID failure.  
Да, zfs RAIDZ убить сложнее, но возможно.

---

<div class="post-metadata">

**Author:** ![d4rk4](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/d4rk4/32/68_2.png) [@d4rk4](https://forum.storj.io/u/d4rk4)\
**Post date:** [April 7, 2024, 8:41am UTC](https://forum.storj.io/t/topic/25649/47 "2024-04-07T08:41:28Z")

</div>

> [@Alexey](#):
>
> Именно это запрещено делать по условиям [Node Operator Terms & Conditions](https://www.storj.io/node-operator-terms-conditions)  
> Вы решили нарушить - получайте предсказуемый результат. Правила обычно написаны “кровью”.

Допустим, но тогда объясните что не так с киллсвитчем на _12RYDKnKqrByfHDrx3ACxe3w1THnJ8txN765qTWeYFdFV5YqSBu_ =)

Я за вас отвечу, он не успевает отработать. Плюс повторюсь, кейс с использованием диска другим сервисом кроме стораджа, который тоже пишет на диск. Именно для этого нужна крутилка для настройки киллсвитча.

UPD: решение с киллсвитчем на 500мб скорее всего не плохо работало, когда было мало трафика в сети, сейчас вангую к вам прибижит много людей с такой-же проблемой, даже те у кого выделенный диск под сторадж. Т.к. по умолчанию нода принимает 25 коннектов, следовательно киллсвитч даже если не настраивается должен высчитываться динамически на основе данных из конфига по количеству коннектов \* на максимальный размер чанка, который может приехать. Но если бы я был менеджером продукта, я бы сделал по умолчанию динамический киллсвитч, который можно перенастроить через конфиг ноды.

UPD2:

> [@Alexey](#):
>
> Вы не должны запускать более одного узла на диск (пул - это один диск для системы).

Ну это один из кейсов. А если например у меня ZFS + SAN и пачка серверов? В ToS есть где-то требования к организации хранилища, может быть там написано что диск должен быть один физически и обязательно подключен интерфейсом SATA напрямую в ноду?

UPD3: Кстати покажите конкретный пункт ToS запрещающий мне запускать более одного узла на одном диске, я что-то не нашел. Не то, что бы это был мой кейс, просто интересно.

UPD4: Отлично вы [захрадкодили](https://github.com/storj/storj/blob/d601509eca53ae1a808762a9bf0f905e5562e571/satellite/overlay/config.go#L52) минимальное место ноды на стороне спутника 🤦‍♂️

---

<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:** [April 7, 2024, 9:50am UTC](https://forum.storj.io/t/topic/25649/48 "2024-04-07T09:50:30Z")

</div>

> [@d4rk4](#):
>
> Я за вас отвечу, он не успевает отработать. Плюс повторюсь, кейс с использованием диска другим сервисом кроме стораджа, который тоже пишет на диск. Именно для этого нужна крутилка для настройки киллсвитча.

По идее - он должен отрабатывать, актуальное свободное место в выделении/на диске запрашивается каждый раз, когда запрашивается загрузка кусочка (вы это можете видеть в логах).  
Вот если ваша дисковая подсистема немного лукавит - тогда такое возможно. Я бы порекомендовал покопать в эту сторону (никто больше не репортил такую проблему). И я даже не очень представляю, как это воспроизвести.

> [@d4rk4](#):
>
> может быть там написано что диск должен быть один физически и обязательно подключен интерфейсом SATA напрямую в ноду?

нет конечно. Мы не хотим ограничивать пользователей какой-то технологией. Просто требование, чтобы один узел - как минимум один диск (заметьте - не наоборот).

> [@d4rk4](#):
>
> UPD3: Кстати покажите конкретный пункт ToS запрещающий мне запускать более одного узла на одном диске, я что-то не нашел.

> - 4.1.4.1. Have a minimum of one (1) hard drive and one (1) processor core dedicated to each Storage Node;

> [@d4rk4](#):
>
> UPD4: Отлично вы [захрадкодили](https://github.com/storj/storj/blob/d601509eca53ae1a808762a9bf0f905e5562e571/satellite/overlay/config.go#L52) минимальное место ноды на стороне спутника 🤦‍♂️

Как обычно - pull requests are welcome!  
Особенно если у вас есть вариант, как это сделать правильно, это поможет многим Операторам!  
Сейчас изменения в storagenode имеют низкий приоритет, но участие Сообщества это кардинально меняет.

---

<div class="post-metadata">

**Author:** ![d4rk4](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/d4rk4/32/68_2.png) [@d4rk4](https://forum.storj.io/u/d4rk4)\
**Post date:** [April 7, 2024, 11:03am UTC](https://forum.storj.io/t/topic/25649/49 "2024-04-07T11:03:59Z")

</div>

> [@Alexey](#):
>
> По идее - он должен отрабатывать, актуальное свободное место в выделении/на диске запрашивается каждый раз, когда запрашивается загрузка кусочка (вы это можете видеть в логах).  
> Вот если ваша дисковая подсистема немного лукавит - тогда такое возможно. Я бы порекомендовал покопать в эту сторону (никто больше не репортил такую проблему). И я даже не очень представляю, как это воспроизвести.

Не надо сваливать на дисковую подсистему повторюсь это RAID5 на ZeusIOPS дисках, однако это вообще никак не влияет, т.к. у вас тут решение дефектив бай дезижн, т.к. при текущей реализации когда [оставшееся место форс репорта](https://github.com/storj/storj/blob/d601509eca53ae1a808762a9bf0f905e5562e571/storagenode/monitor/monitor.go#L59C2-L59C18) равно минимальному месту которое [определяется на спутнике](https://github.com/storj/storj/blob/d601509eca53ae1a808762a9bf0f905e5562e571/satellite/overlay/config.go#L52), у вас всегда будет лаг в несколько чанков с КАЖДОГО спутника. И хорошо, если они маленькие.

> [@Alexey](#):
>
> 4.1.4.1. Have a minimum of one (1) hard drive and one (1) processor core dedicated to each Storage Node;

Это можно в любую сторону трактовать.

> [@Alexey](#):
>
> Как обычно - pull requests are welcome!  
> Особенно если у вас есть вариант, как это сделать правильно, это поможет многим Операторам!

Во первых мне за это не платят, во вторых это нарушает ваш ToS 🤣

> 4.1.3. **You will not modify or attempt to modify the Storage Node Software for any purpose including but not limited** to attempting to circumvent the audit, bypass security, manipulate the performance of, or otherwise disrupt the Storage Services for any reason, including but not limited to attempting to increase the amount of data stored or bandwidth utilized or the amount of Storage Node Fees, as defined herein, and you will not otherwise interfere with the operation of the Storage Services.

> [@Alexey](#):
>
> Сейчас изменения в storagenode имеют низкий приоритет

Кстати забавно, с учетом того, что вокруг storagenode построен вообще весь проект.

---

<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:** [April 7, 2024, 2:34pm UTC](https://forum.storj.io/t/topic/25649/50 "2024-04-07T14:34:55Z")

</div>

> [@d4rk4](#):
>
> Во первых мне за это не платят, во вторых это нарушает ваш ToS 🤣

Да, не платят, это Open source проект. И каким же образом это нарушает ToS?! (Не нарушает, проверено всеми бюрократами, кроме российских).

> [@d4rk4](#):
>
> что вокруг storagenode построен вообще весь проект.

Вообще-то, вокруг клиентов. Партнёры тоже важны, но они читали ToS и приняли его. Если кто-то не читал, ну, наверное, время пришло, и надо прочитать. Принять или идти искать что-то лучше, если оно существует.

---

<div class="post-metadata">

**Author:** ![d4rk4](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/d4rk4/32/68_2.png) [@d4rk4](https://forum.storj.io/u/d4rk4)\
**Post date:** [April 7, 2024, 3:01pm UTC](https://forum.storj.io/t/topic/25649/51 "2024-04-07T15:01:01Z")

</div>

> [@Alexey](#):
>
> Да, не платят, это Open source проект.

Вы путаете опенсорс и коммерческий опенсорс с закрытой экосистемой.

> [@Alexey](#):
>
> И каким же образом это нарушает ToS?!

Ну не я там написал черным по белому, что код ноды модифицировать нельзя. Поговорите чтоль со своими юристами, чтобы исправили.

---

<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:** [April 13, 2024, 11:59am UTC](https://forum.storj.io/t/topic/25649/52 "2024-04-13T11:59:51Z")

</div>

А вы путаете OpenSource и закрытые системы. Этот проект - OpenSource. Практически полностью (кроме имплементаци платежей… но вы тут сами разберётесь, верно?).  
Код узла исправить можно, но присоединять его после к публичной Storj - нет. Понимаете разницу?

[Previous page](https://forum.storj.io/t/topic/25649.md?page=2)