The Grafana data however suggest that the drop in audit score happened after the update.
It is still recovering though, being at 99.08 % actually.
How about log size? Can it be set to rotate and auto-delete?
So, you need to have logs at least -12h before the event
12 hours? I thought if you fail audits the score would reflect it much faster.
This is a standard timeframe when the node will check-in for sure. It should update the reputation more often, how often is specified in the configuration.
docker exec -it storagenode ./storagenode setup --help | grep "reputation"
The main info here - you need to have past logs before the noticeable fall in audits. If you use a default parameters, it should be between 4h-8h, or 12h for sure if there were an offline events.
See
docker exec -it storagenode ./storagenode setup --help | grep "often"
Now at 99.21 % again.
Now at 99.83 %. Whatever the cause was, it must have been a short impact only and itâs no longer present. Very weird.
I have the same, the only error was as in the GET_REPAIR failed because of invalid signature thread.
But since your logs are gone we cannot verify that.
My 14th month old node has just got a 96.68 % audit score from eu1.storj.io:7777 (and no other satellite), for the first time ever. No failed audits in the logs over the last several days.
On the run_earnings scripts itâs sayings itâs a 8.29% Disq (whatever that means).
Itâs running on ZFS and has had no crashes - only ever gracefully restarted on upgrade - guaranteed no missing files.
Take it, itâs a satellite/internet connection issue if not a bug.
Actually looking in the logs, seems like eu1 is asking for a piece as part of a GET_REPAIR that Iâve never had uploaded to me - well not uploaded to me in the last 366 days as I rotate logs at that point. That isnât goodâŚ
It means youâre 8.29% on the way to being disqualified. DQ happens at 100%.
Yes it is very weird, that the score only dropped for this satellite. Meanwhile it keeps going back up and is at 99.98 %.