Stob
August 6, 2021, 6:04pm
2
Hi @pietro ,
Sorry for your loss. If your node is failing audits by giving out bad data, or accepting an audit request but not responding fully to the request in a timely fashion then it is possible to be disqualified that quickly.
In the log file you can look far any entries with ‘WARN’ or ‘FATAL’ or ‘ERROR’. I don’t use linux but these might work?
grep -B 3 -i fatal /mnt/storagenode_appConfig/node.log
This is regarding the audits -
# 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.
show original