А как вы его получите? Вы же должны проверять сколько у вас осталось в выделении, а не на диске.
Этим вы себе ноги связали и привязали к батарее. Настолько диск тормозит?
Если да - может не та ФС? или нет спец. девайса? Если последнее, да ещё если у вас не RAIDZ, зачем вообще zfs тут? она же просто тормоз без тюнинга?
С чего вы вообще взяли, что у меня один диск?
Это пул из 17 raidz по 4 диска, с метадатой на двух 3-way SSD зеркалах и L2ARC из 8 SAS SSD (2x Oracle F80).
В любом случае аппаратный конфиг хранилища никак не относится к проблеме, которая заключается в том, что в логике расчета свободного места вообще нет привязки к фактическому свободному месту на диске (с ваших слов).
тем хуже. Почти любой RAID работает со скоростью самого медленного диска в пуле. Особенно - RAID с parity, а все остальные массивы не надёжны. Зачем вообще тогда начинать? Один узел - один диск и у вас больше не будет проблем с вероятностью 99%.
есть, как исключение. Даже два
Это плохо для всех, клиент может получить ошибку во время загрузки и файл не будет загружен. Ваш узел будет реже предлагаться клиентам. А если он ещё перестанет отвечать на аудиты, то online score упадёт, начнутся удаления кусочков (потому что они восстановились на более надёжные узлы) и прочие радости, а по достижении “почётного” статуса “я был оффлайн 30 дней”, узел будет дисквалифицирован.
Алексей, я не просил вас давать мне советы как правильно мне строить систему хранения, на которой уже 4 года без проблем работает несколько нод.
Если знаете, то подскажите почему свободное место считается не корректно, если на “диск” пишет что-то еще кроме ноды стораджа (мы же помним что вы призываете не использовать выделенное железо)?
Если не знаете, то просто пройдите мимо и позовите например @elek, а не пытайтесь меня лечить рандомными советами вообще никак не связанными с описываемой проблемой.
Я уже понял, то вы не понимаете как работает ZFS, что такое vdev и шедулер в ZFS в частности.
причина - ошибки filewalkers.
можно поискать walk и error|failed|ERROR в логах.
поэтому именно с ними и возникают проблемы. Ещё BTRFS. И Windows VM на Proxmox/VMware.
Нет таких ошибок в логах, проверил по нескольким нодам прежде чем создать тред.
Как и как часто определяется фактическое свободное место? Можно ли как-то сократить интервалы проверки?
после успешного завершения всех filewalkers (для каждого сателлита в отдельности) и обновления БД.
Периодичность у всех разная,
если ошибок с filewalker нет, и данные не сбрасываются после перезапуска, БД скорее всего тоже не повреждены (я бы посоветовал их проверить, даже если вы не нуждаетесь в моих советах).
Если нет никаких ошибок - значит всё должно работать и разница может быть только от сдвига по времени (удаления файлов происходят отсроченно, через сборщик мусора).
# how frequently expired pieces are collected
# collector.interval: 1h0m0s
Если это тот collector про который вы говорите, то получается раз в час.
Правильно ли я понял что по факту свободное место пересчитывается (если ничто не зафейлилось) только 1-2 раза в неделю по максимальному интервалу из всех filewalkers - gc-filewalker?
да, вы правы, collector работает с этим интервалом. Этот обходчик удаляет прокисшие кусочки у которых клиент задал срок годности.
оно пересчитывается после успешного завершения каждого filewalkers, то есть минимум каждый час, максимум 1-2 раза в неделю.
Всем доброго времени суток. Мне конечно же все равно, но с определением свободного места у меня есть замечание - в моей системе на базе Синолоджи дашбоард показывает только и исключительно относительно указанного пула для Storj, свободное же место в системе живет своей жизнью. Например в дашбоарде показывает свободно 5,2 ТБ по факту у меня стабильно свободно ~2 ТБ
Причина та же - filewalkers должны проходить успешно, чтобы они могли обновить данные в БД, БД должны быть исправны и у вас в логах не должно быть ошибок, связанных ни с теми, ни с другими.
Если вы отключили запуск used space filewalker на старте, его рекомендуется включить обратно и перезапустить узел.
А где в контейнере увидеть текущий конфиг для filewalker? То что дает докер по конфигу вообще не содержит намеков на filewalker
В узлах используется 5 filewalkers:
Конфигурируются далеко не все.
used-space-filewalker$ docker exec -it storagenode ./storagenode setup --help | grep scan
--storage2.piece-scan-on-startup if set to true, all pieces disk usage is recalculated
on startup (default true)
gc-filewalkerне настраивается, Bloom filter для него отправляется сателлитами 1-2 раза в неделю
retainпрактически не настраивается, он выполняется после того, как gc-filewalker отыщет мусор, который надо переместить в trash.
$ docker exec -it storagenode ./storagenode setup --help | grep retain
--retain.concurrency int how many concurrent retain requests can be processed
at the same time. (default 5)
--retain.max-time-skew duration allows for small differences in the satellite and
storagenode clocks (default 72h0m0s)
--retain.status storj.Status allows configuration to enable, disable, or test
retain requests from the satellite. Options: (disabled/enabled/debug) (default enabled)
--storage2.retain-time-buffer duration allows for small differences in the satellite and
storagenode clocks (default 48h0m0s)
collector$ docker exec -it storagenode ./storagenode setup --help | grep "collector\."
--collector.interval duration how frequently expired pieces are collected (default
1h0m0s)
piece:trashне настраивается, запускается каждый день
Ещё отдельно можно включить или выключить lazy mode для used-space-filewalker и gc-filewalker:
$ docker exec -it storagenode ./storagenode setup --help | grep "filewalk"
--pieces.enable-lazy-filewalker run garbage collection and used-space calculation
filewalkers as a separate subprocess with lower IO priority (default true)
Кстати я вижу, что и gc-filewalker прилетает, но отрабатывает за одну секунду, без ошибок. Как результат ничего не удаляется, при этом сейчас выполняются все условия (все типы волкеров отрабатывают успешно), но фактическое свободное место все равно не пересчитывается.
Куда еще копать?
gc-filewalker собирает мусор, а retain следом должен перемещать найденное в trash. Между ними, правда, может пройти несколько часов.
Однако если у вас не совпадает фактически занятое место на диске с тем, что показывает как занятое на доске, значит used-space-filewalker не прошёл, он может идти несколько дней, зависит от файловой системы и отклика диска, особенно в режиме lazy.
Ещё может быть разница, если вы используете exFAT, там размер кластера 128 KiB, поэтому использоваться места будет в разы больше, чем размер данных.
Алексей, вы нейросеть не умеющая сохранять контекст? Уже несколько раз упоминалось, что это ZFS и речь про СВОБОДНОЕ место.
Вот кстати проходы used-space-filewalker за сегодня:
Apr 01 01:10:00 50 storagenode[49658]: 2024-04-01T01:10:00Z INFO lazyfilewalker.used-space-filewalker starting subprocess {"Process": "storagenode", "satelliteID": "12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs"}
Apr 01 01:10:00 50 storagenode[49658]: 2024-04-01T01:10:00Z INFO lazyfilewalker.used-space-filewalker subprocess started {"Process": "storagenode", "satelliteID": "12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs"}
Apr 01 01:10:00 50 storagenode[49658]: 2024-04-01T01:10:00Z INFO lazyfilewalker.used-space-filewalker.subprocess Database started {"Process": "storagenode", "satelliteID": "12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs", "Process": "storagenode"}
Apr 01 01:10:00 50 storagenode[49658]: 2024-04-01T01:10:00Z INFO lazyfilewalker.used-space-filewalker.subprocess used-space-filewalker started {"Process": "storagenode", "satelliteID": "12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs", "Process": "storagenode"}
Apr 01 01:27:55 50 storagenode[49658]: 2024-04-01T01:27:55Z INFO lazyfilewalker.used-space-filewalker.subprocess used-space-filewalker completed {"Process": "storagenode", "satelliteID": "12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs", "Process": "storagenode", "piecesTotal": 7665259106304, "piecesContentSize": 7660071269376}
Apr 01 01:27:55 50 storagenode[49658]: 2024-04-01T01:27:55Z INFO lazyfilewalker.used-space-filewalker subprocess finished successfully {"Process": "storagenode", "satelliteID": "12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs"}
Apr 01 01:27:55 50 storagenode[49658]: 2024-04-01T01:27:55Z INFO lazyfilewalker.used-space-filewalker starting subprocess {"Process": "storagenode", "satelliteID": "12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S"}
Apr 01 01:27:55 50 storagenode[49658]: 2024-04-01T01:27:55Z INFO lazyfilewalker.used-space-filewalker subprocess started {"Process": "storagenode", "satelliteID": "12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S"}
Apr 01 01:27:55 50 storagenode[49658]: 2024-04-01T01:27:55Z INFO lazyfilewalker.used-space-filewalker.subprocess Database started {"Process": "storagenode", "satelliteID": "12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S", "Process": "storagenode"}
Apr 01 01:27:55 50 storagenode[49658]: 2024-04-01T01:27:55Z INFO lazyfilewalker.used-space-filewalker.subprocess used-space-filewalker started {"Process": "storagenode", "satelliteID": "12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S", "Process": "storagenode"}
Apr 01 02:05:55 50 storagenode[49658]: 2024-04-01T02:05:55Z INFO lazyfilewalker.used-space-filewalker.subprocess used-space-filewalker completed {"Process": "storagenode", "satelliteID": "12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S", "Process": "storagenode", "piecesTotal": 9227589394632, "piecesContentSize": 9197398841544}
Apr 01 02:05:55 50 storagenode[49658]: 2024-04-01T02:05:55Z INFO lazyfilewalker.used-space-filewalker subprocess finished successfully {"Process": "storagenode", "satelliteID": "12EayRS2V1kEsWESU9QMRseFhdxYxKicsiFmxrsLZHeLUtdps3S"}
Apr 01 02:05:55 50 storagenode[49658]: 2024-04-01T02:05:55Z INFO lazyfilewalker.used-space-filewalker starting subprocess {"Process": "storagenode", "satelliteID": "121RTSDpyNZVcEU84Ticf2L1ntiuUimbWgfATz21tuvgk3vzoA6"}
Apr 01 02:05:55 50 storagenode[49658]: 2024-04-01T02:05:55Z INFO lazyfilewalker.used-space-filewalker subprocess started {"Process": "storagenode", "satelliteID": "121RTSDpyNZVcEU84Ticf2L1ntiuUimbWgfATz21tuvgk3vzoA6"}
Apr 01 02:05:55 50 storagenode[49658]: 2024-04-01T02:05:55Z INFO lazyfilewalker.used-space-filewalker.subprocess Database started {"Process": "storagenode", "satelliteID": "121RTSDpyNZVcEU84Ticf2L1ntiuUimbWgfATz21tuvgk3vzoA6", "Process": "storagenode"}
Apr 01 02:05:55 50 storagenode[49658]: 2024-04-01T02:05:55Z INFO lazyfilewalker.used-space-filewalker.subprocess used-space-filewalker started {"Process": "storagenode", "satelliteID": "121RTSDpyNZVcEU84Ticf2L1ntiuUimbWgfATz21tuvgk3vzoA6", "Process": "storagenode"}
Apr 01 02:10:55 50 storagenode[49658]: 2024-04-01T02:10:55Z INFO lazyfilewalker.used-space-filewalker.subprocess used-space-filewalker completed {"Process": "storagenode", "satelliteID": "121RTSDpyNZVcEU84Ticf2L1ntiuUimbWgfATz21tuvgk3vzoA6", "Process": "storagenode", "piecesTotal": 2187546420736, "piecesContentSize": 2185497425408}
Apr 01 02:10:55 50 storagenode[49658]: 2024-04-01T02:10:55Z INFO lazyfilewalker.used-space-filewalker subprocess finished successfully {"Process": "storagenode", "satelliteID": "121RTSDpyNZVcEU84Ticf2L1ntiuUimbWgfATz21tuvgk3vzoA6"}
Apr 01 02:10:55 50 storagenode[49658]: 2024-04-01T02:10:55Z INFO lazyfilewalker.used-space-filewalker starting subprocess {"Process": "storagenode", "satelliteID": "1wFTAgs9DP5RSnCqKV1eLf6N9wtk4EAtmN5DpSxcs8EjT69tGE"}
Apr 01 02:10:55 50 storagenode[49658]: 2024-04-01T02:10:55Z INFO lazyfilewalker.used-space-filewalker subprocess started {"Process": "storagenode", "satelliteID": "1wFTAgs9DP5RSnCqKV1eLf6N9wtk4EAtmN5DpSxcs8EjT69tGE"}
Apr 01 02:10:55 50 storagenode[49658]: 2024-04-01T02:10:55Z INFO lazyfilewalker.used-space-filewalker.subprocess Database started {"Process": "storagenode", "satelliteID": "1wFTAgs9DP5RSnCqKV1eLf6N9wtk4EAtmN5DpSxcs8EjT69tGE", "Process": "storagenode"}
Apr 01 02:10:55 50 storagenode[49658]: 2024-04-01T02:10:55Z INFO lazyfilewalker.used-space-filewalker.subprocess used-space-filewalker started {"Process": "storagenode", "satelliteID": "1wFTAgs9DP5RSnCqKV1eLf6N9wtk4EAtmN5DpSxcs8EjT69tGE", "Process": "storagenode"}
Apr 01 02:12:53 50 storagenode[49658]: 2024-04-01T02:12:53Z INFO lazyfilewalker.used-space-filewalker.subprocess used-space-filewalker completed {"Process": "storagenode", "satelliteID": "1wFTAgs9DP5RSnCqKV1eLf6N9wtk4EAtmN5DpSxcs8EjT69tGE", "piecesContentSize": 5244915601664, "Process": "storagenode", "piecesTotal": 5246237338880}
Apr 01 02:12:53 50 storagenode[49658]: 2024-04-01T02:12:53Z INFO lazyfilewalker.used-space-filewalker subprocess finished successfully {"Process": "storagenode", "satelliteID": "1wFTAgs9DP5RSnCqKV1eLf6N9wtk4EAtmN5DpSxcs8EjT69tGE"}
Спасибо за новый титул.
То что диски под ZFS ни о чём не говорит: вы можете создать volume (block device) и отформатировать его как угодно.
Хотя, почти все случаи расхождения в использовании места почему-то по странному совпадению обычно происходят на ZFS, BTRFS, Windows VM на Linux host, NTFS под Linux.
Но моя ошибка заключалась в том, что я сразу не задал вопрос правильно. Меня интересовала не ФС на физическом диске, а ФС диска, подключенного к узлу.
Если ошибок, связанных с БД у вас в логах нет, занятое место на диске (du --si -s /srv/storj/50/storage/blobs) должно быть очень близко к тому, что показывает dashboard.
Теперь вижу, что не нейросеть, а просто очень уставший человек, которого задолбали одним и тем-же вопросом про занятое пространство.
Алексей, у меня другая, но более важная проблема - нода(ы) не рассчитывает(ют) правильно фактическое свободное место на диске. Сейчас идет достаточно много ингресса (суммарно я получаю около 1Тб в день, на все свои ноды) и скоро при таком тренде произойдет полное заполнение свободного места, на некоторых из них. Не смотря на то что указан лимит свободного места в 5Тб в конфиге нод, я вижу риски, что данные стораджа займут все свободное пространство и ноды упадут и я не смогу их перезапустить, пока не добавлю свободного места.
Это не совсем правильное поведение, нужно либо понять почему текущий механизм определения свободного пространства сломан, либо все-таки добавить в логику определения места, вызов statfs(), что выглядит более правильным и надежным решением.
Видимо если ближайшие пару недель вы не сможете решить эту проблему, то мне придется делать форк клиента, разбираться в нем и вкорячивать вызов statfs для определения фактического свободного места.
@Alexey FYI, используемое место +/- совпадает, чего нельзя сказать о свободном:
root@50:~# du --si -s /opt/storj/data/storage/
25T /opt/storj/data/storage/
root@50:~# df -h | grep archive/storj
archive/storj/50 47T 23T 25T 48% /opt/storj/data/storage
Ноды упадут не потому что закончится свободное место а потому что вы задекларировали всему миру что вы выделяете место для стораджа одно, а по факту всех “обманули” , реально выделив меньше. В рекомендациях написано - выделяйте фактического места на 5% больше чем декларируете (точно не помню цифры) - как раз с учетом возникающего мусора. Все в ваших руках как говорится ))
Расскажите пожалуйста как-бы вы выделяли место на “диске”, свободное место на котором может меняться динамически? Каждый раз бы правили конфиги нод и перезапускали бы их при каждом добавлении дисков в пул или при исчерпании места другими сервисами?
