там вообще 500Гб с копейками. Так хочется понять в чем косяк в ФС. Вроде бы данных в ФС объективно больше чем показывает нода. Какие настройки ФС не правильные? В чем косяк ФС? Повторюсь, есть точно такой же диск, на такой же ФС, с такими же настройками, на нем бежит другая нода, с ней все ок, она уже заполнилась полгода назад и с тех пор работает без проблем. Разница в том что там нода другой версии v1.63.1
ja ne ponimaju gde zdes problema? kakie tsifry ne shoditsa?
А это что скажет, если указать папку с зфс?
du -h -c /zfsfolder|tail -1
ja ne ponimaju gde zdes problema? kakie tsifry ne shoditsa?
Места на диске фактически занято больше, чем показывает дашборд сторжа.
a mozhno poluchit realnye dannye? ili faktichiskie pro kotorye idjot rech?
А что за модели дисков? Может у них какиенить отличия в размере сектора есть? Или один из них, например, вообще smr.
ja ne siljon v zfs, no pomnju v forume kto-to upominal 4to esli v zfs razmer sektora bolshoi, to faely budut zanimat bolshe mesta, chem oni v reale est.
Выше есть результаты du разными способами, которые просил Алексей.
# du --si -d 1 /mnt/storj2
root@home:~# du --si -d 1 /mnt/storj2
1,7T /mnt/storj2/storj
1,7T /mnt/storj2
du -h -d 1 /mnt/storj2 вижу те же самые 1,5 Тб
1,5T /mnt/storj2/storj
1,5T /mnt/storj2
Модель диска указана в первоначальном сообщении:
WDC WD20EFRX-68EUZN0
Размер блока 128к, так же указано выше в обсуждении:
# zfs get recordsize
NAME PROPERTY VALUE SOURCE
storj recordsize 128K default
storj2 recordsize 128K default
Может в папке temp 200 гигов спряталось? 
Выше проверяли уже эту папку. Там 10 мегабайт.
Идеи всё… В качестве бреда можно еще полностью копирнуть папку на другой диск (не zfs) и сравнить. Исключив тем самым проблемы с размером блока. Дальше видимо только уже лезть в саму СУБД и пофайлово сравнивать что там лежит с тем, что есть на самом деле
Маловероятно. У меня все узлы обновились до 1.63.1 - занятое место показывают адекватно, правда NTFS.
Пожалуйста покажите результат:
du --si --apparent-size -d 1 /mnt/storj2/storj
~# du --si --apparent-size -d 1 /mnt/storj2/storj
1,3T /mnt/storj2/storj/storage
316M /mnt/storj2/storj/orders
1,3T /mnt/storj2/storj
потери на файловой системе 400GB, но есть всё ещё разница в 120GB
du --si --apparent-size -d 1 /mnt/storj2/storj/storage
правильно я понимаю, что добавление в config.yaml
storage2.piece-scan-on-startup: true
может решить данную проблему и количество занятого места будет актуализировано? Просто я прочитал смежные темы про filewalker, но так и не понял решает ли это мою проблему или нет.
Если вы не добавляли эту опцию, то она по умолчанию true, так что поведение не изменится. Если вы удаляли БД и пересоздали её пустой, то filewalker должен был её заполнить корректной информацией.
Встречался только один случай, когда он не мог заполнить информацию - оператор использовал NTFS на Linux, и какой-то (какие-то) файл(ы) был(и) поврежден(ы). После миграции на ext4 проблема решилась, но узел был дисквалифицирован за потерю данных (возможно файлы были давно повреждены, но только после обновления начальных значений для audit score и увеличения порога до 95% вместо 60%, это наконец-то было выявлено).