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

**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:** 20\
**Page:** 1

<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:** [March 28, 2024, 8:28am UTC](https://forum.storj.io/t/topic/25649/1 "2024-03-28T08:28:38Z")

</div>

Стораж призывает не использовать отдельную инфраструктуру для хранения, а использовать то, что есть. Итак следуя этому концепту у меня есть сервер бекапов и видеонаблюдения на который тоже пишутся данные. Недавно я обнаружил, что Storj не корректно определяет свободное место на диске. Пример на скриншоте. На самом деле свободного места несколько меньше:

```auto
archive/storj/50 50T 22T 28T 44% /srv/storj/50

```

 ![image](https://storj-s3.bcdn.literatehosting.net/original/2X/a/a03a7aef2faff7b15153d311bcc7f3e5285a4b72.png)

Внимание вопрос, что нужно подкрутить в конфиге ноды, что-бы нода видела плюс-минус актуальную ситуацию по свободному месту? Как я понимаю есть отдельный механизм который раз в какое-то время проверяет свободное место, но его данные судя по всему не очень актуальны, текущие настройки ноды выглядят как-то так:

```auto
storage2.cache-sync-interval: 15m0s
storage2.database-dir: /opt/storj/db
storage2.max-concurrent-requests: 50
storage2.monitor.minimum-disk-space: 5.0 TB
storage2.orders.path: /opt/storj/orders
storage2.piece-scan-on-startup: true

```

---

<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:** [March 28, 2024, 10:27am UTC](https://forum.storj.io/t/topic/25649/2 "2024-03-28T10:27:36Z")

</div>

Maybe it’s the difference between TB and TiB

 ![1](https://storj-s3.bcdn.literatehosting.net/original/2X/9/92cc0bb59718f95e4798213489c1df48eb9b945e.png)

---

<div class="post-metadata">

**Author:** ![kocoten1992](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/kocoten1992/32/7819_2.png) [@kocoten1992](https://forum.storj.io/u/kocoten1992)\
**Post date:** [March 28, 2024, 10:47am UTC](https://forum.storj.io/t/topic/25649/3 "2024-03-28T10:47:29Z")

</div>

Impressive, how long your node been running to achieve used 24TB?

---

<div class="post-metadata">

**Author:** ![Roxor](https://storj.bcdn.literatehosting.com/letter_avatar/roxor/32/5_5575768a8748004e209b776fc1b2916d.png) [@Roxor](https://forum.storj.io/u/Roxor)\
**Post date:** [March 28, 2024, 11:08am UTC](https://forum.storj.io/t/topic/25649/4 "2024-03-28T11:08:31Z")

</div>

> [@kocoten1992](#):
>
> …how long your node been running to achieve used 24TB?

…and how long does filewalker take? It probably doesn’t even complete before Storj pushes out the next node version and it restarts again 🙂

---

<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:** [March 28, 2024, 11:11am UTC](https://forum.storj.io/t/topic/25649/5 "2024-03-28T11:11:49Z")

</div>

Filewalker runs about 4-6h

---

<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:** [March 28, 2024, 11:12am UTC](https://forum.storj.io/t/topic/25649/6 "2024-03-28T11:12:39Z")

</div>

Anyway, it must be current free space minus 5TB.

---

<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:** [March 28, 2024, 11:51am UTC](https://forum.storj.io/t/topic/25649/7 "2024-03-28T11:51:22Z")

</div>

Actually I have some discrepancies too:

 ![Cattura](https://storj-s3.bcdn.literatehosting.net/original/2X/0/0a187b22c2fdae6f200aa31421452f6af12683c4.png)

Have you seen this threahd?

> [@Disk usage discrepancy?](https://forum.storj.io/t/disk-usage-discrepancy/24715):
>
> something wrong with my node???..online score just drop down…how to get 100% again?

---

<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:** [March 28, 2024, 11:56am UTC](https://forum.storj.io/t/topic/25649/8 "2024-03-28T11:56:15Z")

</div>

Here is the opposite case, my question related to free space correct calculation/tunables for frequent free space recalc. I really don’t have Idea why the node can’t execute

```auto
syscall.Statfs()

```

for free space calculation.

---

<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:** [March 29, 2024, 8:19am UTC](https://forum.storj.io/t/topic/25649/9 "2024-03-29T08:19:30Z")

</div>

Это широко обсуждается в уже приведённом треде. Кратко - процессы filewalkers должны завершаться успешно для каждого сателлита до перезапуска узла. Если сканирование не завершилось и узел был перезапущен (по любой причине), уже накопленная информация теряется и узел начинает сканирование с нуля.  
Это должно быть пофикшено в новых версиях,

> [@Debugging space usage discrepancies](https://forum.storj.io/t/debugging-space-usage-discrepancies/24874/3):
>
> Looks to be a bug, garbage\_collection\_pieces\_count and garbage\_collection\_pieces\_skipped are swapped when lazy file walker is used (default). This should fix the problem: [https://review.dev.storj.io/c/storj/storj/+/12076](https://review.dev.storj.io/c/storj/storj/+/12076) Until that, you can check the value of ...\_skipped Not: it’s still not very useful metrics, as the value is updated after any execution. If two satellites have totally different values, the first one may not be visible, only by max/min fields. I am considering to add the s…

> [@Debugging space usage discrepancies](https://forum.storj.io/t/debugging-space-usage-discrepancies/24874/22):
>
> Related issue: TLDR; with high number of segments on one node, the bloom filter is less effective as it should be. Fix is on the way. The easiest way to check if you are affected is counting the blobs in the storage directory ukfu6bhbboxilvt7jrwlqk7y2tapb5d2r2tsmj2sjxvw5qaaaaaa or v4weeab67sbgvnbwd5z7tweqsqqun7qox2agpbxy44mqqaaaaaaa folders ([US or EU satellite](https://forum.storj.io/t/satellite-info-address-id-blobs-folder-hex/17183)). If you have at least 14M blobs (in one satellite folder) and see big discrepancies, feel free to post your numbers as comment on …

В качестве промежуточного решения можно отключить lazy mode:

> [@Huge drop of Average disk space used](https://forum.storj.io/t/huge-drop-of-average-disk-space-used/23328/16):
>
> Please try to disable lazy filewalker, it will turn on the normal (with a normal priority):
> 
> ```auto
> # run garbage collection and used-space calculation filewalkers
> # as a separate subprocess with lower IO priority (default true)
> pieces.enable-lazy-filewalker: false
> 
> ```
> 
> save the config and restart the node. If you use docker, you may provide this flag after the image name: `--pieces.enable-lazy-filewalker=false`

---

<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:** [March 29, 2024, 9:04am UTC](https://forum.storj.io/t/topic/25649/10 "2024-03-29T09:04:17Z")

</div>

Зачем для подсчета СВОБОДНОГО пространства нужен fillewalker если это просто вызов одной функции statfs?  
Я честно говоря вообще не нашел как считается свободное пространство во время работы ноды. Вижу только проверку свободного места во время старта. Неужели вы берете свободное место на старте, вычисляете занятое, вычитаете занятое из информации полученной при запуске ноды и получаете обводное?  
Если что ноды v100.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:** [March 30, 2024, 4:31am UTC](https://forum.storj.io/t/topic/25649/11 "2024-03-30T04:31:54Z")

</div>

Оно считает использованное место и считает свободное в разрешённом размере (а не сколько на диске осталось), как разницу между разрешённым и занятым.  
Если filewalkers завершились успешно - они обновляют БД (из которой информация отображается на вашей dashboard), для каждого сателлита по-отдельности.  
Проверять их статус можно так:

> [@Storagenode.exe stopping for too long, for 10h+](https://forum.storj.io/t/storagenode-exe-stopping-for-too-long-for-10h/25316/12):
>
> Windows/PowerShell Logs should be at least info level Used space filewalker Regulated by the parameter in the config.yaml file or as a command line argument (add -- before the parameter, remove :, place it after the image name in your docker run command): # if set to true, all pieces disk usage is recalculated on startup (default true) storage2.piece-scan-on-startup: true to watch for a progress: cat "C:\Program Files\Storj\Storage Node\*.log" -Wait | sls "used-space-filewalker" | sls "sta…

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

Мы берём предоставленное место, считаем занятое (только `storage/blobs`, `storage/trash`) и вычитаем из предоставленного, отображая свободное место в разрешённом для использования.  
Например, вы разрешили использовать 7ТБ из 8ТБ, мы возьмём 7ТБ (проверим, не превышает ли это размер диска, основываясь на (возможно устаревших) данных по использованию из БД, после этого либо примем предложенный вариант, либо установим минимальный размер из предложенного и реального размера диска), потом запустим подсчёт занятого и обновим БД. На dashboard в качестве свободного будет отображаться разница между 7ТБ и использованием из БД.  
Каждый раз, когда клиенты загружают данные на ваш диск, удаляют их или скачивают, мы обновляем БД. Поэтому если у вас нет проблем с БД (`database is locked`, `database is malformed`, `file is not a database`, и т.д.), и нет чего-то, что использует место на этом диске тоже (chia например), то теоретически подсчёт на старте не нужен - данные из БД должны совпадать с реальностью.  
Однако если другие обходчики (`gc-filewalker`, `retain`, `piece:trash`, `collector`) падают до завершения своей работы, БД не будет обновлена и данные “разъедутся”. На этот случай как раз используется обходчик на старте (`used-space-filewalker`).

---

<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:** [March 30, 2024, 5:25am UTC](https://forum.storj.io/t/topic/25649/12 "2024-03-30T05:25:26Z")

</div>

Как раз проблема возникает на нодах которые шарят дисковое пространство с чем-то (в моем случае бекапы и архив NVR).

---

<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:** [March 30, 2024, 7:51am UTC](https://forum.storj.io/t/topic/25649/13 "2024-03-30T07:51:46Z")

</div>

Тогда вам нельзя выключать обходчик на старте. И нужно обеспечить необходимую производительность дисков, чтобы он не упал по таймауту.  
В случае Windows NTFS:

1. проверить и исправить ошибки диска,
2. провести дефрагментацию,
3. включить автоматическую дефрагментацию, если вы её выключили
4. Удалить 8.3 имена: [NTFS Disable 8dot3name](https://forum.storj.io/t/ntfs-disable-8dot3name/25624)

В случае Linux - использовать ext4.  
В любом случае не использовать exFAT, network filesystems (NFS, SMB/CIFS, SSHFS, …).  
Желательно не использовать Windows VM on Linux (VMware, Proxmox, KVM, …), если у вас Linux host - используйте docker/LXC.

---

<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:** [March 30, 2024, 8:02am UTC](https://forum.storj.io/t/topic/25649/14 "2024-03-30T08:02:15Z")

</div>

У меня бездокерные ноды в LXC, в качестве ФС ZFS с persistent-ARC (l2arc\_headroom=0).  
Полный проход filewalker на самых больших нодах занимет максимум 6 часов.  
Проблема в том, что при текущей реализации, нода не проверяет актуальное свободное место, включение/отключение сканирования на старте вообще влиять не должно.  
Проблема у вас в оверинжиненрнутой логике: во первых ваше решение в принципе не работает при таком кейсе, во вторых для определения свободного места, на самом деле достаточно делать вызов statfs раз в n-минут, что до сих пор почему-то не реализовано.

---

<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:** [March 30, 2024, 8:13am UTC](https://forum.storj.io/t/topic/25649/15 "2024-03-30T08:13:24Z")

</div>

> [@d4rk4](#):
>
> включение/отключение сканирования на старте вообще влиять не должно.

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

> [@d4rk4](#):
>
> Проблема у вас в оверинжиненрнутой логике: во первых ваше решение в принципе не работает при таком кейсе

Прекрасно работает. Главное - чтобы диск успевал до таймаута. Если не успевает - увы. У меня на тупой “железной” винде и одиночных дисках - успевает.  
Так как вы используете ZFS и знаете, что эта ФС работает в разы медленнее (без special device on SSD), чем ext4 ([BTRFS vs EXT4 vs ZFS Filesystem for storj](https://forum.storj.io/t/btrfs-vs-ext4-vs-zfs-filesystem-for-storj/18069)), и у вас есть сторонние сервисы, использующие тот же “диск”, вам необходимо проводить это сканирование.

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

абсолютно бесполезен. Узел должен посчитать только “свои” файлы и проверять занятость не против информации с диска, а против выделения места, которое вы решили предоставить. Особенно в случае

> [@d4rk4](#):
>
> на нодах которые шарят дисковое пространство с чем-то

---

<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:** [March 30, 2024, 8:14am UTC](https://forum.storj.io/t/topic/25649/16 "2024-03-30T08:14:50Z")

</div>

Алексей, на всякий случай напомню какую проблему мы тут решаем: некорректное определение _ **СВОБОДНОГО** _ места.

---

<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:** [March 30, 2024, 8:15am UTC](https://forum.storj.io/t/topic/25649/17 "2024-03-30T08:15:23Z")

</div>

… Внутри ВЫДЕЛЕНИЯ, а не на диске. Улавливаете разницу?  
Считайте это “виртуальным диском”. Вы указали, что готовы пошарить 7ТБ, вот внутри этих 7ТБ узел и должен проверять, сколько осталось.

---

<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:** [March 30, 2024, 8:19am UTC](https://forum.storj.io/t/topic/25649/18 "2024-03-30T08:19:13Z")

</div>

Окей, кейс: выделено, 250Т, свободно фактически на диске 30Т, минимум свободного для ноды 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:** [March 30, 2024, 8:24am UTC](https://forum.storj.io/t/topic/25649/19 "2024-03-30T08:24:06Z")

</div>

> [@d4rk4](#):
>
> сколько должно отображаться свободного места в дашборде?

> [@d4rk4](#):
>
> минимум свободного для ноды 5Тб.

вот столько и должно, если не было проблем с обходчиками (dashboard показывает то, что в БД, а БД обновляется операциями и обходчиками). Если нет проблем с блокировками в БД и она не сломана, то информация должна совпадать практически 1:1.

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

Когда будет менее или равно 500МБ в выделении или в крайнем случае - на диске (если БД не актуальны).

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

Свободное место - вычисляемое значение, как разница между выделением и известным узлу использованием. Использование узел берёт из БД.  
Файловые обходчики и все операции с данными должны поддерживать БД в актуальном состоянии (если не сдохли сами и не сломалась БД).

---

<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:** [March 30, 2024, 8:27am UTC](https://forum.storj.io/t/topic/25649/20 "2024-03-30T08:27:04Z")

</div>

Пожалуйста обратите внимание на настроки, кторые я предоставил в первом посте, прежде чем писать ответы и не выглядеть глупо:

```auto
storage2.cache-sync-interval: 15m0s
storage2.database-dir: /opt/storj/db
storage2.max-concurrent-requests: 50
storage2.monitor.minimum-disk-space: 5.0 TB
storage2.orders.path: /opt/storj/orders
storage2.piece-scan-on-startup: true

```

> [@Alexey](#):
>
> Свободное место - вычисляемое как разница между выделением и известным узлу использованием. Использование узел берёт из БД.

Если это действительно так, то это в корне не верно, потому, что вот во всей этой логике нет момента, где нода получает текущее фактическое свободное пространство.

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