Disqualified after 2 hours of [edit] failed audits?

Alexey · July 5, 2020, 12:04pm

I just want to point out to the similar discussion:

The suspension mode is a good suggestion from the SNO point of view, but a very bad from the satellites’ and customers’ points of view:

your node doesn’t have requested files, but they can be requested by customers and they got an error “file not found”;

it can trigger the repair job, because all pieces on your node will be marked as temporary unhealthy;

if the repair job has been triggered, the payment for repairing would be taken from the satellite’s operator pocket, not from the held amount of the suspended node;

the suspended node will lose the repaired pieces, because they will be stored on more reliable nodes;

the satellite operator will pay for inaccessible data from its pocket until you fix the problem or until a week is gone.

The current implementation of suspension will be used only if your node would answer with unknown error. It’s not so great number of nodes as if were taken into account the “no such file” errors.

github.com

storj/storj/blob/5786595d141ff8b8c8be21e5e8696dd73e04d08d/docs/blueprints/audit-suspend.md

# Storagenode "Suspension" State Blueprint

## Introduction

Currently, when a storagenode is audited for an erasure share, there are five possible outcomes:

1. Success: The node responds with the correct data
2. Failure: The node responds with incorrect data
3. Offline: The node cannot be contacted
4. Contained: The node can be contacted, but the connection times out before all the data can be received by the satellite
5. Unknown: The node responds with any other error

Only cases 1 and 2 directly affect a node's audit reputation, which can cause disqualification.

When the [downtime tracking service](./storage-node-downtime-tracking.md) is fully implemented, case 3 can indirectly cause a disqualification.

Case 4 can also indirectly cause disqualification, since a node placed in containment mode will be re-audited at some point with the same 5 potential outcomes.

Case 5 is the only situation where there is currently no potential penalty for responding to an audit with some type of error. Fortunately, having this case has allowed us to find, diagnose, and fix several problems with storagenodes, increasing network durability. Unfortunately, it allows us to perceive nodes that consistently respond to audits with unknown errors as "healthy", giving us an inflated view of durability.

This file has been truncated. show original