Стораж призывает не использовать отдельную инфраструктуру для хранения, а использовать то, что есть. Итак следуя этому концепту у меня есть сервер бекапов и видеонаблюдения на который тоже пишутся данные. Недавно я обнаружил, что Storj не корректно определяет свободное место на диске. Пример на скриншоте. На самом деле свободного места несколько меньше:
Внимание вопрос, что нужно подкрутить в конфиге ноды, что-бы нода видела плюс-минус актуальную ситуацию по свободному месту? Как я понимаю есть отдельный механизм который раз в какое-то время проверяет свободное место, но его данные судя по всему не очень актуальны, текущие настройки ноды выглядят как-то так:
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
Это широко обсуждается в уже приведённом треде. Кратко - процессы filewalkers должны завершаться успешно для каждого сателлита до перезапуска узла. Если сканирование не завершилось и узел был перезапущен (по любой причине), уже накопленная информация теряется и узел начинает сканирование с нуля.
Это должно быть пофикшено в новых версиях,
В качестве промежуточного решения можно отключить lazy mode:
Зачем для подсчета СВОБОДНОГО пространства нужен fillewalker если это просто вызов одной функции statfs?
Я честно говоря вообще не нашел как считается свободное пространство во время работы ноды. Вижу только проверку свободного места во время старта. Неужели вы берете свободное место на старте, вычисляете занятое, вычитаете занятое из информации полученной при запуске ноды и получаете обводное?
Если что ноды v100.3
Оно считает использованное место и считает свободное в разрешённом размере (а не сколько на диске осталось), как разницу между разрешённым и занятым.
Если filewalkers завершились успешно - они обновляют БД (из которой информация отображается на вашей dashboard), для каждого сателлита по-отдельности.
Проверять их статус можно так:
Мы берём предоставленное место, считаем занятое (только 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).
Тогда вам нельзя выключать обходчик на старте. И нужно обеспечить необходимую производительность дисков, чтобы он не упал по таймауту.
В случае Windows NTFS:
проверить и исправить ошибки диска,
провести дефрагментацию,
включить автоматическую дефрагментацию, если вы её выключили
В случае Linux - использовать ext4.
В любом случае не использовать exFAT, network filesystems (NFS, SMB/CIFS, SSHFS, …).
Желательно не использовать Windows VM on Linux (VMware, Proxmox, KVM, …), если у вас Linux host - используйте docker/LXC.
У меня бездокерные ноды в LXC, в качестве ФС ZFS с persistent-ARC (l2arc_headroom=0).
Полный проход filewalker на самых больших нодах занимет максимум 6 часов.
Проблема в том, что при текущей реализации, нода не проверяет актуальное свободное место, включение/отключение сканирования на старте вообще влиять не должно.
Проблема у вас в оверинжиненрнутой логике: во первых ваше решение в принципе не работает при таком кейсе, во вторых для определения свободного места, на самом деле достаточно делать вызов statfs раз в n-минут, что до сих пор почему-то не реализовано.
Вы можете это легко проверить - закомментируйте отключение, сохраните конфиг и перезапустите узел. Понаблюдайте через хотя бы сутки.
Прекрасно работает. Главное - чтобы диск успевал до таймаута. Если не успевает - увы. У меня на тупой “железной” винде и одиночных дисках - успевает.
Так как вы используете ZFS и знаете, что эта ФС работает в разы медленнее (без special device on SSD), чем ext4 (BTRFS vs EXT4 vs ZFS Filesystem for storj), и у вас есть сторонние сервисы, использующие тот же “диск”, вам необходимо проводить это сканирование.
абсолютно бесполезен. Узел должен посчитать только “свои” файлы и проверять занятость не против информации с диска, а против выделения места, которое вы решили предоставить. Особенно в случае
… Внутри ВЫДЕЛЕНИЯ, а не на диске. Улавливаете разницу?
Считайте это “виртуальным диском”. Вы указали, что готовы пошарить 7ТБ, вот внутри этих 7ТБ узел и должен проверять, сколько осталось.
Окей, кейс: выделено, 250Т, свободно фактически на диске 30Т, минимум свободного для ноды 5Тб.
Внимание вопрос:
сколько должно отображаться свободного места в дашборде?
когда нода престанет принимать новые данные?
и самый важный вопрос этого треда:
как работает механизм определения фактического свободного места? как подтюнить частоту пересчета фактического свободного места?
как я понимаю, сейчас никак, потому что у вас сейчас проблема с логикой в коде.
вот столько и должно, если не было проблем с обходчиками (dashboard показывает то, что в БД, а БД обновляется операциями и обходчиками). Если нет проблем с блокировками в БД и она не сломана, то информация должна совпадать практически 1:1.
Когда будет менее или равно 500МБ в выделении или в крайнем случае - на диске (если БД не актуальны).
Свободное место - вычисляемое значение, как разница между выделением и известным узлу использованием. Использование узел берёт из БД.
Файловые обходчики и все операции с данными должны поддерживать БД в актуальном состоянии (если не сдохли сами и не сломалась БД).
Если это действительно так, то это в корне не верно, потому, что вот во всей этой логике нет момента, где нода получает текущее фактическое свободное пространство.
