Свободное место ноды

Приветствую, коллеги!

Имеется два диска по 2Tb. Оба диска имеют файловую систему zfs. Диски размечены одинаково. Каждый диск отдан под одну ноду. Одна нода заполнена полностью:

2022-09-17_13-59-13_NEXUS4_ae6d239f-ccba-427c-8504-262cb6034e05

По этой ноде в операционной системе вижу адекватную информацию при вызове команды df -h

Файл.система Размер Использовано Дост Использовано% Cмонтировано в
storj 1,8T 1,7T 62G 97% /mnt/storj

Есть второй диск, нода еще не заполнена полностью. По нему такая информация на данный момент в дашборде:

2022-09-17_14-01-07_NEXUS4_98735f31-476c-4660-ba1b-d277a7255aa1

Но по данном диску ОС при вызове df -h я вижу следующую картину:

Файл.система Размер Использовано Дост Использовано% Cмонтировано в
storj2 1,8T 1,5T 315G 83% /mnt/storj2

Не совсем понятно каким образом на дашборде 1,15Тб, а в ОС 1,5 Тб. Окей, делаю по всей папке du -h -d 1 /mnt/storj2 вижу те же самые 1,5 Тб

1,5T /mnt/storj2/storj
1,5T /mnt/storj2

ashift у дисков одинаковый:

zpool get ashift

NAME PROPERTY VALUE SOURCE
storj ashift 12 local
storj2 ashift 12 local

Оба диска одинаковой модели: WDC WD20EFRX-68EUZN0

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

Скорее всего некорректная информация в БД. Проверьте БД на ошибки: https://support.storj.io/hc/en-us/articles/360029309111-How-to-fix-a-database-disk-image-is-malformed-

Все DB файлы вроде бы в порядке:

# find ./ -iname "*.db" -maxdepth 1 -print0 -exec sqlite3 '{}' 'PRAGMA integrity_check;' ';'
find: warning: you have specified the global option -maxdepth after the argument -iname, but global options are not positional, i.e., -maxdepth affects tests specified before it as well as those specified after it.  Please specify global options before other arguments.
./bandwidth.dbok
./heldamount.dbok
./info.dbok
./notifications.dbok
./orders.dbok
./piece_expiration.dbok
./piece_spaced_used.dbok
./pieceinfo.dbok
./pricing.dbok
./reputation.dbok
./satellites.dbok
./secret.dbok
./storage_usage.dbok
./used_serial.dbok

Это на остановленной ноде. Я еще заметил что все остальные ноды обновлены только до версии v1.62.3, проблемная же нода обновлена до v1.63.1, что странно. watchtower запущен и работает.

Ошибок в базе данных не обнаружено, это уже хорошо.
С размерами нужно ещё иметь ввиду, что ПО Storj использует систему мер Си, так что занятых 1.15TB это 1.05TiB. du и df используют бинарную систему по умолчанию. Так что для корректного сравнения надо использовать --si вместо -h.

Вы не отключали для этого узла filewalker? Если отключали - включите обратно и перезапустите узел. Если не выключали просто перезапустите узел. Если через несколько часов не вычислит используемые данные, тогда проверьте там папку tmp в папке с данными, если там много данных, остановите узел и очистите эту папку tmp, затем запустите узел обратно.

Если после этого всё равно останется разница, тогда я могу предложить только попробовать пересоздать БД piece_spaced_used.db следуя инструкции https://support.storj.io/hc/en-us/articles/4403032417044-How-to-fix-database-file-is-not-a-database-error

Обновления устанавливаются автоматически, последние образы docker версии включают в себя updater, watchtower теперь обновляет только базовый образ. updater производит обновление узла внутри контейнера в соответствии с волнами, как и binary версии.

df --si дает следующую инфу по тому:

storj2 2,0T 1,7T 300G 85% /mnt/storj2

du с ним солидарен:

# du --si -d 1 /mnt/storj2
root@home:~# du --si -d 1 /mnt/storj2
1,7T    /mnt/storj2/storj
1,7T    /mnt/storj2

на диске ничего кроме данных одного контейнера storj нет.

Ничего не отключал, все работает так как описано в первоначальной инструкции по установке / запуску ноды. Все ноды работают внутри одного LXD контейнера, в каждую ноду смонтирован соответствующий ей диск с данными и папка с identity. Ноду вчера в очередной раз останавливал, удалял (docker rm), и снова запускал.

Папку tmp внутри контейнера? Она расположена на другом томе, да и файлом там нет вообще, если бы и были, то они не влияют на занимаемое место на проблемном томе ZFS. Если речь про папку temp которая расположена внутри /mnt/storj2 то там небольшое количество данных, около 10 мегабайт.

Сделал описанное. После запуска ноды, количество занятого места на дашборде ноды не изменилось. Надо какое то время подождать?

При создании размер блока указали 1мб, и забыли компрессию включить? :slight_smile:

Да, я про эту.

filewalker выполняется какое-то время, зависит от диска, так что нужно подождать. Данные на dashboard должны были показывать сначала ноль, потом постепенно должно появиться корректное занятое место.

Кстати, валидное замечание от @serger001

Тут есть проблема. Насколько я понял инструкцию, применительно к моему случаю пункт 6 “Move backed up databases back with replace” надо было интерпретировать так, заменить все файлы кроме storage_usage.db и далее запустить ноду. Если я так делаю, то получаю цикличный перезапуск ноды:

{"log":"Error: Error creating tables for master database on storagenode: migrate: no such table: storage_usage\n","stream":"stdout","time":"2022-09-19T08:06:08.572249486Z"}
{"log":"\u0009storj.io/storj/storagenode/storagenodedb.(*DB).Migration.func21:2035\n","stream":"stdout","time":"2022-09-19T08:06:08.572279903Z"}
{"log":"\u0009storj.io/storj/private/migrate.Func.Run:307\n","stream":"stdout","time":"2022-09-19T08:06:08.572284847Z"}
{"log":"\u0009storj.io/storj/private/migrate.(*Migration).Run.func1:197\n","stream":"stdout","time":"2022-09-19T08:06:08.57228867Z"}
{"log":"\u0009storj.io/private/dbutil/txutil.withTxOnce:75\n","stream":"stdout","time":"2022-09-19T08:06:08.572292393Z"}
{"log":"\u0009storj.io/private/dbutil/txutil.WithTx:36\n","stream":"stdout","time":"2022-09-19T08:06:08.572295997Z"}
{"log":"\u0009storj.io/storj/private/migrate.(*Migration).Run:196\n","stream":"stdout","time":"2022-09-19T08:06:08.572299199Z"}
{"log":"\u0009storj.io/storj/storagenode/storagenodedb.(*DB).MigrateToLatest:347\n","stream":"stdout","time":"2022-09-19T08:06:08.572302342Z"}
{"log":"\u0009main.cmdRun:226\n","stream":"stdout","time":"2022-09-19T08:06:08.572305505Z"}
{"log":"\u0009storj.io/private/process.cleanup.func1.4:378\n","stream":"stdout","time":"2022-09-19T08:06:08.572308648Z"}
{"log":"\u0009storj.io/private/process.cleanup.func1:396\n","stream":"stdout","time":"2022-09-19T08:06:08.57231168Z"}
{"log":"\u0009github.com/spf13/cobra.(*Command).execute:852\n","stream":"stdout","time":"2022-09-19T08:06:08.572314783Z"}
{"log":"\u0009github.com/spf13/cobra.(*Command).ExecuteC:960\n","stream":"stdout","time":"2022-09-19T08:06:08.572317866Z"}
{"log":"\u0009github.com/spf13/cobra.(*Command).Execute:897\n","stream":"stdout","time":"2022-09-19T08:06:08.572329466Z"}
{"log":"\u0009storj.io/private/process.ExecWithCustomConfigAndLogger:93\n","stream":"stdout","time":"2022-09-19T08:06:08.572332788Z"}
{"log":"\u0009main.main:478\n","stream":"stdout","time":"2022-09-19T08:06:08.572335961Z"}
{"log":"\u0009runtime.main:255\n","stream":"stdout","time":"2022-09-19T08:06:08.572339024Z"}
{"log":"2022-09-19 08:06:08,574 INFO exited: storagenode (exit status 1; not expected)\n","stream":"stdout","time":"2022-09-19T08:06:08.574329668Z"}

в итоге по данной инструкции я заменил ВСЕ файлы файлами из бекапа чтобы запустить ноду, естественно на дашборде получил тоже самое, что наверно не правильно.

наоборот, нужно файл БД удалить/переименовать, остальные переместить. При старте они все создадутся пустыми, остановить узел, вернуть родные БД, кроме того, который и должен стать пустым. Таким образом будет пересоздан только один файл.

Это и сделал первоначально:

  1. остановил ноду
  2. переместил все db файлы в backup
  3. запустил ноду
  4. создались все файлы пустые
  5. остановил ноду
  6. перенес в папку где создались пустые файлы все файлы из backup кроме файла storage_usage.db

как результат получил цикличный перезапуск ноды с логами которые я прикрепил к прыдыдущему сообщению.

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

# zfs get recordsize
NAME    PROPERTY    VALUE    SOURCE
storj   recordsize  128K     default
storj2  recordsize  128K     default

возможно я что то не так понимаю и имеется ввиду какой то другой параметр.

Повторюсь с первой нодой все ок, со второй проблема.

Это странно. БД должны были создаться корректными сразу, может узел не успел завершить создание?

Заметил следующее. После действий.
1 остановил ноду
2 переместил все db файлы в backup
3 запустил ноду
4 создались все файлы пустые

Я так же получаю циклический перезапуск ноды с логами вида:

{"log":"2022-09-19 08:35:46,082 INFO spawned: 'storagenode' with pid 44\n","stream":"stdout","time":"2022-09-19T08:35:46.083275589Z"}
{"log":"2022-09-19 08:35:46,083 WARN received SIGQUIT indicating exit request\n","stream":"stdout","time":"2022-09-19T08:35:46.083601701Z"}
{"log":"2022-09-19 08:35:46,083 INFO waiting for storagenode, processes-exit-eventlistener, storagenode-updater to die\n","stream":"stdout","time":"2022-09-19T08:35:46.084076985Z"}
{"log":"2022-09-19T08:35:46.083Z\u0009INFO\u0009Got a signal from the OS: \"terminated\"\u0009{\"Process\": \"storagenode-updater\"}\n","stream":"stdout","time":"2022-09-19T08:35:46.084394936Z"}
{"log":"2022-09-19 08:35:46,086 INFO stopped: storagenode-updater (exit status 0)\n","stream":"stdout","time":"2022-09-19T08:35:46.086883129Z"}
{"log":"2022-09-19T08:35:46.121Z\u0009INFO\u0009Configuration loaded\u0009{\"Process\": \"storagenode\", \"Location\": \"/app/config/config.yaml\"}\n","stream":"stdout","time":"2022-09-19T08:35:46.121491484Z"}
{"log":"2022-09-19T08:35:46.121Z\u0009INFO\u0009Anonymized tracing enabled\u0009{\"Process\": \"storagenode\"}\n","stream":"stdout","time":"2022-09-19T08:35:46.12181302Z"}
{"log":"2022-09-19T08:35:46.122Z\u0009INFO\u0009Operator email\u0009{\"Process\": \"storagenode\", \"Address\": \"root@istas.ru\"}\n","stream":"stdout","time":"2022-09-19T08:35:46.122972897Z"}
{"log":"2022-09-19T08:35:46.122Z\u0009INFO\u0009Operator wallet\u0009{\"Process\": \"storagenode\", \"Address\": \"\"}\n","stream":"stdout","time":"2022-09-19T08:35:46.123236137Z"}
{"log":"2022-09-19T08:35:46.826Z\u0009INFO\u0009Telemetry enabled\u0009{\"Process\": \"storagenode\", \"instance ID\": \"\"}\n","stream":"stdout","time":"2022-09-19T08:35:46.827002188Z"}
{"log":"2022-09-19T08:35:46.855Z\u0009INFO\u0009db.migration\u0009Database Version\u0009{\"Process\": \"storagenode\", \"version\": 54}\n","stream":"stdout","time":"2022-09-19T08:35:46.855366399Z"}
{"log":"2022-09-19T08:35:47.146Z\u0009INFO\u0009preflight:localtime\u0009start checking local system clock with trusted satellites' system clock.\u0009{\"Process\": \"storagenode\"}\n","stream":"stdout","time":"2022-09-19T08:35:47.147192012Z"}
{"log":"2022-09-19T08:35:48.080Z\u0009INFO\u0009preflight:localtime\u0009local system clock is in sync with trusted satellites' system clock.\u0009{\"Process\": \"storagenode\"}\n","stream":"stdout","time":"2022-09-19T08:35:48.081058755Z"}
{"log":"2022-09-19T08:35:48.081Z\u0009INFO\u0009Node  started\u0009{\"Process\": \"storagenode\"}\n","stream":"stdout","time":"2022-09-19T08:35:48.081284897Z"}
{"log":"2022-09-19T08:35:48.081Z\u0009INFO\u0009Public server started on [::]:28967\u0009{\"Process\": \"storagenode\"}\n","stream":"stdout","time":"2022-09-19T08:35:48.081297304Z"}
{"log":"2022-09-19T08:35:48.081Z\u0009INFO\u0009Private server started on 127.0.0.1:7778\u0009{\"Process\": \"storagenode\"}\n","stream":"stdout","time":"2022-09-19T08:35:48.081400997Z"}
{"log":"2022-09-19T08:35:48.466Z\u0009WARN\u0009piecestore:monitor\u0009Disk space is less than requested. Allocated space is\u0009{\"Process\": \"storagenode\", \"bytes\": 301784891392}\n","stream":"stdout","time":"2022-09-19T08:35:48.466587408Z"}
{"log":"2022-09-19T08:35:48.466Z\u0009ERROR\u0009piecestore:monitor\u0009Total disk space is less than required minimum\u0009{\"Process\": \"storagenode\", \"bytes\": 500000000000}\n","stream":"stdout","time":"2022-09-19T08:35:48.466637828Z"}
{"log":"2022-09-19T08:35:48.466Z\u0009INFO\u0009trust\u0009Scheduling next refresh\u0009{\"Process\": \"storagenode\", \"after\": \"4h15m26.802766256s\"}\n","stream":"stdout","time":"2022-09-19T08:35:48.466650185Z"}
{"log":"2022-09-19T08:35:48.466Z\u0009ERROR\u0009services\u0009unexpected shutdown of a runner\u0009{\"Process\": \"storagenode\", \"name\": \"piecestore:monitor\", \"error\": \"piecestore monitor: disk space requirement not met\", \"errorVerbose\": \"piecestore monitor: disk space requirement not met\\n\\tstorj.io/storj/storagenode/monitor.(*Service).Run:125\\n\\tstorj.io/storj/private/lifecycle.(*Group).Run.func2.1:87\\n\\truntime/pprof.Do:40\\n\\tstorj.io/storj/private/lifecycle.(*Group).Run.func2:86\\n\\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57\"}\n","stream":"stdout","time":"2022-09-19T08:35:48.466837724Z"}
{"log":"2022-09-19T08:35:48.466Z\u0009ERROR\u0009piecestore:cache\u0009error getting current used space: \u0009{\"Process\": \"storagenode\", \"error\": \"context canceled; context canceled; context canceled; context canceled; context canceled; context canceled\", \"errorVerbose\": \"group:\\n--- context canceled\\n--- context canceled\\n--- context canceled\\n--- context canceled\\n--- context canceled\\n--- context canceled\"}\n","stream":"stdout","time":"2022-09-19T08:35:48.467022088Z"}
{"log":"2022-09-19T08:35:48.467Z\u0009ERROR\u0009pieces:trash\u0009emptying trash failed\u0009{\"Process\": \"storagenode\", \"error\": \"pieces error: filestore error: context canceled\", \"errorVerbose\": \"pieces error: filestore error: context canceled\\n\\tstorj.io/storj/storage/filestore.(*blobStore).EmptyTrash:154\\n\\tstorj.io/storj/storagenode/pieces.(*BlobsUsageCache).EmptyTrash:316\\n\\tstorj.io/storj/storagenode/pieces.(*Store).EmptyTrash:367\\n\\tstorj.io/storj/storagenode/pieces.(*TrashChore).Run.func1:51\\n\\tstorj.io/common/sync2.(*Cycle).Run:99\\n\\tstorj.io/common/sync2.(*Cycle).Start.func1:77\\n\\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57\"}\n","stream":"stdout","time":"2022-09-19T08:35:48.467254609Z"}
{"log":"2022-09-19T08:35:48.467Z\u0009ERROR\u0009pieces:trash\u0009emptying trash failed\u0009{\"Process\": \"storagenode\", \"error\": \"pieces error: filestore error: context canceled\", \"errorVerbose\": \"pieces error: filestore error: context canceled\\n\\tstorj.io/storj/storage/filestore.(*blobStore).EmptyTrash:154\\n\\tstorj.io/storj/storagenode/pieces.(*BlobsUsageCache).EmptyTrash:316\\n\\tstorj.io/storj/storagenode/pieces.(*Store).EmptyTrash:367\\n\\tstorj.io/storj/storagenode/pieces.(*TrashChore).Run.func1:51\\n\\tstorj.io/common/sync2.(*Cycle).Run:99\\n\\tstorj.io/common/sync2.(*Cycle).Start.func1:77\\n\\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57\"}\n","stream":"stdout","time":"2022-09-19T08:35:48.467366724Z"}
{"log":"2022-09-19T08:35:48.467Z\u0009ERROR\u0009pieces:trash\u0009emptying trash failed\u0009{\"Process\": \"storagenode\", \"error\": \"pieces error: filestore error: context canceled\", \"errorVerbose\": \"pieces error: filestore error: context canceled\\n\\tstorj.io/storj/storage/filestore.(*blobStore).EmptyTrash:154\\n\\tstorj.io/storj/storagenode/pieces.(*BlobsUsageCache).EmptyTrash:316\\n\\tstorj.io/storj/storagenode/pieces.(*Store).EmptyTrash:367\\n\\tstorj.io/storj/storagenode/pieces.(*TrashChore).Run.func1:51\\n\\tstorj.io/common/sync2.(*Cycle).Run:99\\n\\tstorj.io/common/sync2.(*Cycle).Start.func1:77\\n\\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57\"}\n","stream":"stdout","time":"2022-09-19T08:35:48.467540985Z"}
{"log":"2022-09-19T08:35:48.467Z\u0009ERROR\u0009pieces:trash\u0009emptying trash failed\u0009{\"Process\": \"storagenode\", \"error\": \"pieces error: filestore error: context canceled\", \"errorVerbose\": \"pieces error: filestore error: context canceled\\n\\tstorj.io/storj/storage/filestore.(*blobStore).EmptyTrash:154\\n\\tstorj.io/storj/storagenode/pieces.(*BlobsUsageCache).EmptyTrash:316\\n\\tstorj.io/storj/storagenode/pieces.(*Store).EmptyTrash:367\\n\\tstorj.io/storj/storagenode/pieces.(*TrashChore).Run.func1:51\\n\\tstorj.io/common/sync2.(*Cycle).Run:99\\n\\tstorj.io/common/sync2.(*Cycle).Start.func1:77\\n\\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57\"}\n","stream":"stdout","time":"2022-09-19T08:35:48.467665767Z"}
{"log":"2022-09-19T08:35:48.467Z\u0009ERROR\u0009pieces:trash\u0009emptying trash failed\u0009{\"Process\": \"storagenode\", \"error\": \"pieces error: filestore error: context canceled\", \"errorVerbose\": \"pieces error: filestore error: context canceled\\n\\tstorj.io/storj/storage/filestore.(*blobStore).EmptyTrash:154\\n\\tstorj.io/storj/storagenode/pieces.(*BlobsUsageCache).EmptyTrash:316\\n\\tstorj.io/storj/storagenode/pieces.(*Store).EmptyTrash:367\\n\\tstorj.io/storj/storagenode/pieces.(*TrashChore).Run.func1:51\\n\\tstorj.io/common/sync2.(*Cycle).Run:99\\n\\tstorj.io/common/sync2.(*Cycle).Start.func1:77\\n\\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57\"}\n","stream":"stdout","time":"2022-09-19T08:35:48.467791531Z"}
{"log":"2022-09-19T08:35:48.467Z\u0009ERROR\u0009pieces:trash\u0009emptying trash failed\u0009{\"Process\": \"storagenode\", \"error\": \"pieces error: filestore error: context canceled\", \"errorVerbose\": \"pieces error: filestore error: context canceled\\n\\tstorj.io/storj/storage/filestore.(*blobStore).EmptyTrash:154\\n\\tstorj.io/storj/storagenode/pieces.(*BlobsUsageCache).EmptyTrash:316\\n\\tstorj.io/storj/storagenode/pieces.(*Store).EmptyTrash:367\\n\\tstorj.io/storj/storagenode/pieces.(*TrashChore).Run.func1:51\\n\\tstorj.io/common/sync2.(*Cycle).Run:99\\n\\tstorj.io/common/sync2.(*Cycle).Start.func1:77\\n\\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57\"}\n","stream":"stdout","time":"2022-09-19T08:35:48.467988483Z"}
{"log":"2022-09-19T08:35:48.468Z\u0009ERROR\u0009gracefulexit:chore\u0009error retrieving satellites.\u0009{\"Process\": \"storagenode\", \"error\": \"satellitesdb: context canceled\", \"errorVerbose\": \"satellitesdb: context canceled\\n\\tstorj.io/storj/storagenode/storagenodedb.(*satellitesDB).ListGracefulExits:149\\n\\tstorj.io/storj/storagenode/gracefulexit.(*Service).ListPendingExits:58\\n\\tstorj.io/storj/storagenode/gracefulexit.(*Chore).AddMissing:58\\n\\tstorj.io/common/sync2.(*Cycle).Run:99\\n\\tstorj.io/storj/storagenode/gracefulexit.(*Chore).Run:51\\n\\tstorj.io/storj/private/lifecycle.(*Group).Run.func2.1:87\\n\\truntime/pprof.Do:40\\n\\tstorj.io/storj/private/lifecycle.(*Group).Run.func2:86\\n\\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57\"}\n","stream":"stdout","time":"2022-09-19T08:35:48.468253448Z"}
{"log":"2022-09-19T08:35:48.468Z\u0009ERROR\u0009nodestats:cache\u0009Get pricing-model/join date failed\u0009{\"Process\": \"storagenode\", \"error\": \"context canceled\"}\n","stream":"stdout","time":"2022-09-19T08:35:48.468396616Z"}
{"log":"2022-09-19T08:35:48.468Z\u0009INFO\u0009bandwidth\u0009Performing bandwidth usage rollups\u0009{\"Process\": \"storagenode\"}\n","stream":"stdout","time":"2022-09-19T08:35:48.468408643Z"}
{"log":"2022-09-19T08:35:48.468Z\u0009ERROR\u0009bandwidth\u0009Could not rollup bandwidth usage\u0009{\"Process\": \"storagenode\", \"error\": \"bandwidthdb: context canceled\", \"errorVerbose\": \"bandwidthdb: context canceled\\n\\tstorj.io/storj/storagenode/storagenodedb.(*bandwidthDB).Rollup:301\\n\\tstorj.io/storj/storagenode/bandwidth.(*Service).Rollup:53\\n\\tstorj.io/common/sync2.(*Cycle).Run:99\\n\\tstorj.io/storj/storagenode/bandwidth.(*Service).Run:45\\n\\tstorj.io/storj/private/lifecycle.(*Group).Run.func2.1:87\\n\\truntime/pprof.Do:40\\n\\tstorj.io/storj/private/lifecycle.(*Group).Run.func2:86\\n\\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57\"}\n","stream":"stdout","time":"2022-09-19T08:35:48.468478819Z"}
{"log":"2022-09-19T08:35:48.468Z\u0009ERROR\u0009collector\u0009error during collecting pieces: \u0009{\"Process\": \"storagenode\", \"error\": \"pieceexpirationdb: context canceled\", \"errorVerbose\": \"pieceexpirationdb: context canceled\\n\\tstorj.io/storj/storagenode/storagenodedb.(*pieceExpirationDB).GetExpired:39\\n\\tstorj.io/storj/storagenode/pieces.(*Store).GetExpired:522\\n\\tstorj.io/storj/storagenode/collector.(*Service).Collect:88\\n\\tstorj.io/storj/storagenode/collector.(*Service).Run.func1:57\\n\\tstorj.io/common/sync2.(*Cycle).Run:99\\n\\tstorj.io/storj/storagenode/collector.(*Service).Run:53\\n\\tstorj.io/storj/private/lifecycle.(*Group).Run.func2.1:87\\n\\truntime/pprof.Do:40\\n\\tstorj.io/storj/private/lifecycle.(*Group).Run.func2:86\\n\\tgolang.org/x/sync/errgroup.(*Group).Go.func1:57\"}\n","stream":"stdout","time":"2022-09-19T08:35:48.468500209Z"}
{"log":"2022-09-19T08:35:48.468Z\u0009ERROR\u0009gracefulexit:blobscleaner\u0009couldn't receive satellite's GE status\u0009{\"Process\": \"storagenode\", \"error\": \"context canceled\"}\n","stream":"stdout","time":"2022-09-19T08:35:48.468697151Z"}
{"log":"Error: piecestore monitor: disk space requirement not met\n","stream":"stdout","time":"2022-09-19T08:35:48.707299007Z"}
{"log":"2022-09-19 08:35:48,710 INFO stopped: storagenode (exit status 1)\n","stream":"stdout","time":"2022-09-19T08:35:48.710511321Z"}
{"log":"2022-09-19 08:35:48,711 INFO stopped: processes-exit-eventlistener (terminated by SIGTERM)\n","stream":"stdout","time":"2022-09-19T08:35:48.711233137Z"}

Это нормально? Не совсем понимаю что не так в этой ситуации. Данные об идентификатор ноды и кошельке я удалил из лога. Может быть после этого не создается корректный пустой db файл disk_usage?

Total disk space is less than required minimum не оно? У меня такая ошибка была, когда я из 2tb случайно удалил t, и осталось 2b. И да, в этом случае узел не запускается и циклично перегружается

Дело в том что я когда возвращаю все db файлы обратно из бекапа в рабочую директорию, нода запускается, с той конфигурацией которую я сделал изначально. Скрин выше в первоначальном сообщении. Нода работает, нода принимает и отправляет данные. Вот только я не особо понимаю что будет с заливаемыми файлами в ноду, при такой разнице в использованном месте по версии ноды и по версии ОС. Нода будет все еще думать что у нее полно места свободного, а на самом деле на диске уже нет места. Я чисто случайно обнаружил это несоответствие.

Это ожидаемо, если места свободного меньше 500GB
Можно временно отключить проверку опцией --storage2.monitor.minimum-disk-space 0B, когда filewalker заполнит БД, и занятое место будет отображаться корректно, опцию можно будет убрать.

Так теперь получилось.

  1. остановил ноду
  2. переместил все db файлы в backup
  3. запустил ноду
  4. создались все файлы пустые
  5. остановил ноду
  6. перенес в папку где создались пустые файлы все файлы из backup кроме файла storage_usage.db
  7. запустил ноду.

правильно?

В итоге на дашборде пока по прежнему не правильное значение:

2022-09-19_13-12-21_S-STAROV_fd09a1da-4122-4bc6-a80e-cc6099cb742a

Это нормально?

Вообще не наблюдаю по монитрингу железки что есть какая то дисковая активность которая примерно хоть сколько нибудь выше обычного использования диска. Т.е. вряд ли нода на данном диске выполняет какие то емкие I/O операции как, например, подсчет количества занятого пространства на диске.

В итоге ничего не изменилось, к сожалению. Возможно это баг версии v1.63.1 ? Потому что другие ноды работают на другой версии и с ними все нормально.

В payout information можно будет посмотреть в конце месяца, сколько будет выплачено за хранение. Если за 1.5тб, то косяк в базе. Если за 1.2тб, то косяк в ФС.
Хотя, наверное, можно это уже сейчас посмотреть в статистике за прошлый месяц, если там уже было расхождение.