Yeah it is proven many times. Dependens of nature of “down”. It maybe down some microservices, or locked some table in database.
Something that does not prevent the satellite from set DQ because it is not able to accept responses from a correctly working node.
1 Like
For example if the satellite has problems connecting to the internet. It may decide that the nodes are offline where in fact it is offline.
It most likely would not result in all nodes being disqualified, but some nodes that were marginal may get DQ because of that.
1 Like
I agree, in the past it happened quite often to me that after a satellite update my node’s uptime dropped a lot. Of course the older the nodes got the less impact that had on the dashboard score because it is a useless lifetime value. But satellite downtimes did affect node uptime scores.
Fair enough. But those stats still don’t matter anymore, since there is going to be a new system anyway.
The question remains for the new system as well. If the satellite has problems with its internet connection, will this negatively impact the nodes?
1 Like
It’s interesting that my node dropped from 39% upload successrate to 33% with the new update. I typically don’t care too much about that number but I’m still curious why my node would suddenly drop that obviously.
(And please don’t post things like "traffic is changing all the time, could be different locations, … My nodes have had a stable successrate of 39% since months, no matter the amount or type of traffic and just suddenly dropped directly after the update and stayed at that rate since the update. i use logrotate so rates are always starting fresh at 0am)
To what exactly are you referring?
I don’t have any database is locked errors, neither before nor after the update.
Do you think the current version logs too many cancelled errors compared to the previous version?
5 Likes
Thanks, with this issue it does indeed not make any sense to look at the successrate of uploads until it is fixed.
1 Like
would still be a performance metric tho… even if the number is wrong… 
does kinda make me wonder if the changes in the db location option could have given you a performance decrease or if its simply because the log append comes later and thus the satellite will have more time to send the cancel request which then gets logged…
was thinking about that the other day and it actually sort of makes sense as to why the logs are wrong… the logs report incoming requests, and maybe not relevant requests because they are on a time delay…of when it was sent from the satellite
kinda like my issue with appending logs where it would skip a line from time to time, because i needed to go back in time and grab from fixed points in time instead of one minute back in time. which would be a variable point in time.
anyways i should mention that to littleskunk, think it sort of might explain why the logs are wrong and partly how to fix it…
1 Like
This new feature will be tested intensively any time soon?
I don’t see a reason for that. It is not a critical feature. Even if it is broken we still have garbage collection as fall back. → We don’t need to be careful here.
3 Likes
did you change that on the satellites because i haven’t really seen the db is locked issue for a long time, but might be due to me changing either my max concurrent to infinite in config.yaml or simply that i haven’t rebooted in a while… still going to test to see if i can bring back my db is locked issue before i switch from 1.3.3 to 1.4.2 or whatever it is called now
This bug could explain why my trash folder is high in GB’s used. Almost hit 200GB the other day again.
Unlikely, the transfer actually finishes completely in many cases and pieces even get downloaded later on. These won’t end up in garbage if they complete successfully. So it’s just a misleading log line.
The quite from littleskunk is about something else. I agree that it shouldn’t need to be extensively tested outside of internal testing already done. This will happen automatically and I can already see it doing its job on my node. Since you refer to a bug that as far as I know doesn’t exist in the delete mechanism, I guess you mean the bug with the wrong log line?
This bug about logging but not about space allocation, please not mix it together.
I don’t see it mention in the original post but it looks like in version 1.4.2 they have fixed the console dashboard to now show the correct amount of free space remaining. It’s not fixed on the web dashboard yet but I do see that in the master branch of GitHub (for a future release), they are adding a disk utilization pie chart that shows free space, used space, and trash space. Thanks for fixing these issues Storj team.
1 Like