Windows node останавливается с ошибкой

В общем, вот такая ошибка выдаётся при внезапной остановке узла:
2023-11-09T20:22:21+02:00 FATAL Unrecoverable error {“error”: “piecestore monitor: timed out after 1m0s while verifying readability of storage directory”, “errorVerbose”: “piecestore monitor: timed out after 1m0s while verifying readability of storage directory\n\tstorj.io/storj/storagenode/monitor.(*Service).Run.func1.1:152\n\tstorj.io/common/sync2.(*Cycle).Run:160\n\tstorj.io/storj/storagenode/monitor.(*Service).Run.func1:141\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:75”}

За сегодня третий раз уже. Это диск умирает?

look here

Вам нужно:

  1. Остановить узел
  2. Проверить диск на ошибки и исправить их
  3. Провести дефрагментацию
  4. Включить автоматическую дефрагментацию для этого диска, если вы выключали её (по умолчанию она включена)
  5. Запустить узел

Если остановки из-за ошибок проверки чтения (readability) будут по-прежнему происходить, вам необходимо увеличить два параметра в config.yaml:

менять/добавлять нужно с помощью текстового редактора Notepad++ или Visual Studio Code, не используйте обычный Блокнот или Wordpad, они повредят конфиг. После изменения конфиг нужно явно сохранить (Notepad++ не будет предлагать его сохранить при закрытии) и перезапустить узел или из оснастки Сервисы, или из PowerShell от имени администратора:

Restart-Service storagenode

Если увеличение на 30с не поможет - увеличьте ещё на 30с, сохраните конфиг и перезапустите узел. Повторяйте, пока узел не перестанет останавливаться на ошибке чтения.

Внимание! Если вам придётся увеличить таймаут чтения больше 5 минут, ваш узел находится в опасности дисквалификации! Если узел не сможет предоставлять кусочки для аудита после 5 минут и сделает так три раза для каждого такого кусочка, узел начнёт терять репутацию. Как только audit score упадёт до 96%, узел будет дисквалифицирован.
Поэтому, если таймаут чтения вам пришлось выставить больше 5 минут - ваш узел в опасности, вам необходимо срочно проверить диск на ошибки, возможно он начал выходить из строя.

У вас также могут появиться ошибки проверки записи типа

в этом случае нужно немного увеличить таймаут проверки записи

так же сохранить конфиг и перезапустить узел.
Если будет недостаточно - увеличить ещё на 30с, сохранить конфиг и перезапустить узел. Повторять, пока узел не перестанет останавливаться на ошибках записи.
Если вам придётся увеличить таймаут проверки записи более 5 минут, вам нужно будет так же начать увеличивать интервал проверки на запись (потому что значение по умолчанию для интервала проверок на запись составляет 5 минут):

# how frequently to verify writability of storage directory (default 5m0s)
storage2.monitor.verify-dir-writable-interval: 5m30s

# how long to wait for a storage directory writability verification to complete (default 1m0s)
storage2.monitor.verify-dir-writable-timeout: 5m30s

сохранить конфиг и перезапустить узел.
Имейте ввиду, если вам пришлось увеличить таймаут записи более 5 минут, значит ваш узел так же проигрывает большинство гонок за кусочками другим узлам - он слишком медленный. Это также означает, что у вашего диска есть проблемы и их необходимо устранить.

Здравствуйте! Стопается нода с такой ошибкой:

2023-11-11T19:52:26+03:00 FATAL Unrecoverable error {“error”: “piecestore monitor: timed out after 1m0s while verifying writability of storage directory”, “errorVerbose”: “piecestore monitor: timed out after 1m0s while verifying writability of storage directory\n\tstorj.io/storj/storagenode/monitor.(*Service).Run.func2.1:176\n\tstorj.io/common/sync2.(*Cycle).Run:160\n\tstorj.io/storj/storagenode/monitor.(*Service).Run.func2:165\n\tgolang.org/x/sync/errgroup.(*Group).Go.func1:75”}

Диск проверял на ошибки, все ок. Дефрагментацию делал. Что может быть?

@Alexey will move you there.

Здравствуйте @Sarumanvar,

В вашем случае нужно увеличивать таймаут проверок на запись (writable).

Мне помогло постоянное висение в фоне Hard Disk Sentinel. Он постоянно опрашивает диски и не даёт им свалиться в спящий режим. Может это как раз тот случай.

1 Like

Нашел в чем проблема, перепробовал все, что советовали (кроме редактирования config, т.к. показалось, что увеличение времени ожидания подтверждения записи это как-то неправильно), кабеля менял, chkdisk… диск victoria проверял полностью…,но диск на котором все храниться. Оказалось, что системный диск ssd где стоит ситема и установлена сама программа storj и где, как я понял храниться кеш ордеров, начал умирать, victoria при тесте поверхности показывала сектора с доступом 1s и выше, много секторов. Заменил диск. Может кому поможет.
И сразу вопрос, если, кто еще читает, можно ли в config настроить более оптимально, если есть 32-64гб оперативной памяти свободной, чтобы кеш уходил в оперативку? И если в таком случае я уменьшу таймаут проверки записи, в таком случае нода будет иметь больший приоритет?

В конфиге узла ничего подходящего для этого нет, это задача ОС заниматься кэшированием, не узла.
Windows использует память для дискового кэша, но не так эффективно, как в Linux, поэтому есть костыли в виде PrimoCache.
Однако если вы об использовании кэширования на запись, тогда можете включить в настройках диска кэширование записи.
В обоих случаях вы должны иметь управляемый UPS, чтобы система успела успешно завершить работу до израсходования аккумулятора. Иначе потери данных неизбежны а там и до дисквалификации недалеко.

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