Thanks arrogantrabbit for the explanation, I guessed
it is NOT payed. Nobody is paying for this.
This is not for the client, it’s mostly for SNO to protect from disqualification in case if the satellite would send an incorrect bloom filter and it could remove data which should not be removed.
We will have 7 days to restore wrongly deleted data and fix an issue.
If you delete this data, your node could not recover it and will be DQ for losing it.
See also
@Roberto please do not remove the trash folder unless you want to disqualify your node.
All files older than 7 days will be removed automatically.
1 Like
Same on my Windows node.
There are folders inside with content and last modified date on the folder with content is January 2020!
Deleting it manually. It´s 759GB.
Please do not delete anything manually! Your node will be at risk of disqualification now on!
Check the actual pieces older than 7 days with these scripts instead:
The Creation date is not the same as an expiration date!
Next steps please my friend? Seems I have quite a bunch:
Lazy filewalker is now disabled.
What are parameters for the second run? Your photo is cut. Please do not use screenshots for the text, never, I would appreciate that.
2 Likes
Sorry, was unware.
It´s this command:
“Get-ChildItem E:\Storage\trash\ -File -Recurse | Where-Object {$.LastWriteTime -lt (Get-Date).AddDays(-7)} | Measure-Object -Property Length -Sum | %{“Total {0:f2} MB`ncount {1}” -f ($.Sum/1e6), $_.Count}”
1 Like
The -7 mean that it should count pieces which must be in the trash at this time.
The -8 parameter will show what’s must not be in the trash.
And I guess this last one returned 0 accordingly your screenshot.
This is the “-8” results:
PS C:\Users\Admin> Get-ChildItem e:\Storage\trash\ -File -Recurse | Where-Object {$.LastWriteTime -lt (Get-Date).AddDays(-8)} | Measure-Object -Property Length -Sum | %{“Total {0:f2} MB`ncount {1}” -f ($.Sum/1e6), $_.Count} Total 1173726.04 MB
count 7566064
Which seems to me 1.1TB (roughly) that shoud not be there?
@Alexey still unclear- what to do with old trash folders like this:
they are not empty (for this node more then 300gb+), node restarted several times to initiate filewalker (as u can see- new subfolders were created correctly), latest version is installed
seems that early folders were created during 99-100 version and not automatically deleted by new versions
just to show that its happen on several nodes…
Please use the script instead. The folder name doesn’t help here. It’s created when the node moved pieces to the trash, not when they will expire.
It also depends on the storagenode version, some versions 1.10x.x are aware of a new structure, older versions are not. The current minimum version is 1.99.3
If you use a docker version, it may rollback to the minimum version if you would recreate the container, so the new one moved pieces to the subfolder, but the old one don’t know it yet, so it will use an old approach, i.e. scan pieces every day.
In short - please use the script.
What’s your current version for this node?
It´s on version 1.102.3
1 Like
my nodes are currently 102.x
about the script- as I see its only collecting info not fixing anything right? (if yes- I personally suffer from terabytes of trash that is not deleted atm… and have to move them to bigger disk- script it taking a lot of time on bigger trash folders generating I/o preventing to move %(((
2 Likes
@Alexey any thoughts on it? It’s on version 1.102.3
There’s definitely something wrong here…
Apparently, the older than 8 days files are gone, but for some reason database is not updated.
Before you ask, yes, I check all the databases and all the return results from the check is “ok”.
Looks like it doesn’t delete anything in trash.
But I think you should also run the command on each date folder to check if they hold pieces or not.