On your screenshot you are comparing a measurement in binary units (Windows calculates space in binary units but wrongly shows a decimal units names), but the node calculates space in decimal units, so what’s showed by Windows as 966 wrongly GB (because it’s actually GiB) is 1037.23 GB in decimal (SI) units.
this is already implemented,
# if set to true, all pieces disk usage is recalculated on startup (default true)
# storage2.piece-scan-on-startup: true
just uncomment it, change to false, save the config and restart the node. However, I believe, that you have a different meaning for that filewalker.
What’s actually do, it scans all pieces to calculate used space include trash on start (only), it updates databases after the successful finish. If you disable it, your node will update these databases only after successful operations with the pieces, like uploads new pieces, moving pieces to the trash, removing expired pieces or from the trash, etc.
If you would have a wrong values in databases regarding initially used space, they will remain wrong, just updated with changes (here you may have a virtual overusage by the way due to this).
So, in this case if you have a discrepancy between the real usage and the showed usage, you shouldn’t disable a used-space-filewalker on start to allow the node to update its databases to a correct values.
You need to use scripts to check how many outdated data here, not the creation date (for PowerShell you need to use +8 to see the outdated data, which should be deleted):
However, I believe that we do not account subfolders correctly, so you may have subfolders, which date name is older than 7 days due to this bug. It should be fixed in a new version. Meanwhile you may remove subfolders with date name older than 7 days from the trash.
See:
на русском
На screenshot вы сравниваете десятичные TB с двоичными TiB, они всегда будут не совпадать. Windows показывает место в двоичных единицах измерения (base 2), хотя и показывает их десятичные названия, а узел считает в десятичных единицах измерения (base 10), поэтому Windows 966 якобы GB (а на самом деле GiB), это 1037.23 GB.
Это уже реализовано:
# if set to true, all pieces disk usage is recalculated on startup (default true)
# storage2.piece-scan-on-startup: true
раскомментируйте и измените на false, сохраните конфиг и перезапустите узел.
Однако он делает совсем не то, что вы, наверное, представляете.
Этот параметр запускает used-space-filewalker, чтобы посчитать занятое место, в т.ч. в trash и обновить БД. Если он будет отключён, то узел будет обновлять БД только при операциях с кусочками, т.е. при загрузке, сборке мусора, удалении кусочков из trash и перемещении кусочков в trash.
Но если начальное состояние БД содержало некорректные данные, а вы отключили used-space-filewalker, то они так и останутся хоть и обновлёнными, но некорректными (отсюда и виртуальный overusage).
Поэтому в этом случае (если есть расхождение в использованном месте и отображаемом) вам нельзя отключать его, чтобы узел имел возможность исправить БД на корректное значение для использованного места и trash.
Вам нужно использовать скрипты для подсчёта устаревшей информации в trash, а не дату создания (для PowerShell надо использовать значение +8):
How long does trash stay before getting deleted? - #6 by Alexey
Тем не менее, у нас есть баг, мы не учитываем подпапки в trash больше, а из-за нескольких downgrade версий у вас может быть каша в trash типа такой:
Trash does not go away in 7 days - #57 by jammerdan
В этом случае вы можете удалить вручную подпапки, чья дата модификации (или имя содержащее дату) старше 7 дней.