Disqualified after 3 years

[AndMetal]

@BrightSilence

Sure, if you completely ignore the fact that they implemented the read/write check to exactly solve the problem you outline

My understanding is this fixes the “loose cable” scenario, but not pietro’s which if I read that thread correctly was a system that was still responding (dashboard was still up, was getting and attempting to respond to audits) but the audit data wasn’t making it back to the satellite due to some temporary issue in the kernel (under Docker it sounds like). I feel like my scenario is a little closer to that than a USB drive that lost connection.

@BrightSilence

and conveniently skip over the fact that your non-standard and advised against setup broke that check

Where in the documentation is using Storage Spaces or junctions under Windows advised against? The closest thing I could find was “The network-attached storage location could work, but it is neither supported nor recommended!” (Storage Node - Storj Docs). To be clear this exact same setup has worked flawlessly for YEARS (since August 3rd, 2020). The only major issue I’ve had was updates failing to install automatically a few years ago which I eventually remedied.

@BrightSilence

Have you given thought to why all the topics you found are two years old? Let me give you a hint, no one has run into this issue anymore in more recent times. I wonder why that is…?

Those are just the ones linked to what jammerdan posted (New audit scoring is live). It took me a while to read through them, and unfortunately I don’t have unlimited time to scour the forum, Reddit posts, etc. In reading through some of those posts though, I’m curious if your opinions have changed over the years:

@BrightSilence

Instead of having the satellite deal with this, I think the node software itself should do a better job of monitoring itself. We’ve seen a little too frequently that nodes become basically unresponsive to the point where log lines just stop being written even. But yet responsive enough to still accept the audit challenge.

In my opinion, nodes should monitor their own performance and if they are not capable of responding to a request fast enough, they should just terminate. This saves the satellite from having to find out what is going on and having to distinguish between a node running into issues or a node trying to fool the audit system.

@BrightSilence

@jammerdan

I think worst scenario is what we have right now: Quick disqualification without prior notification, without indication and without the possibility to revoke.

Right, so this is the core issue. And I think most of what we’ve seen recently has some common characteristics. It tends to be that the node becomes unresponsive and doesn’t even log, but apparently does just enough to signal to the satellite that it is still online. I’m with @Alexey that this isn’t all that common, but at the same time, it may be the most common issue that node operators face atm. We’re still dealing with nodes that run into a failure state though and almost certainly not one caused by the node software itself. So ideally we would get better ways to monitor that so we can take better care of our nodes. But I don’t think it’s on Storj to fix the underlying issues here or be more lenient on the requirements.

@BrightSilence

@Pentium100

Then maybe nodes should not be disqualified in 4 hours with no notification and no chance to get them back when the OS freezes?

This may have gotten lost in the discussion, but I definitely agree with this as well. I do think the “when the OS freezes” part is key here though. I think the faster the better to disqualify nodes that have actually lost data or corrupted data.
This problem does need a solution. And for some reason it’s been popping up on the forum more than it did before. Enough that I think it’s something that needs to be looked into. I just don’t agree with all solutions that have been proposed here. I think there are better ways to fix it.