Disqualified - audit 59% on eu1, but i think he got all the files

sure, the hdd seems to work just fine, ran just a regular windows 10 scan disc. I has other node on this harddrive and its fine. i would like to perform some test in cooperation with sattelite to verify statemen: i have lost some files.

because im saying i did not.
(porobably, lest check?)
im making my statement: current audit checking system, faild,
falsly accusing my node of losing of files, but what really happened was just time offline. I dont know how to check it,

im writing here to reach official tech support from storj,
and so it can be seen for everybody as well.

I will link this post from Alexey outlining the reasons a node can currently be disqualified:

I will add that you can also be disqualified if your node is more than 3 versions behind the current version.

1 Like

yea all im saying is i dont belive just words, lets check if that really was the case

First step would be to check your logs for “GET_AUDIT” and “failed” in the same line.

cant find any “failed” in entire 1GB log file, using notepad++,
(the search fuction works checked on “GET_AUDIT”)

so i have 153372 “GET_AUDIT” matches, and yet not 1 “failed” mayby other wording?
edit: (i go lots of “failed” without “” in normal download failed, just not with GET_AUDIT)

Edit2: yeah, “file does” is found only 4 times in entire 1GB storagenode.log, and it refers to:

“Action”: “GET”, “error”: “file does not exist”,

And example of a failed audit from my node (due to missing piece):

You could also process your log file with the community success rate script:

the log does not contain failed audit messages.
it is only on satellite side.

1 Like

The log does in fact contain failed audit messages. You can see an example of one in the post directly above your post.

no way
I mean if a piece is in place, you will not know whether it is faulty or not when audit comes
Here is no log messages for pieces that not lost but broken

Somehow my node still claims that «Running the minimal allowed version: v1.24.0». Storjlings, why is this so?

This was discussed - Keeping your node up to date, changes to storage node software! PLEASE READ this thread!

@Toyoo you even commented further down the thread, but may have missed the original post.

I was mostly complaining that the problem of bad communication is still not solved. I won’t put more effort into complaints until Storj puts more effort into answering complaints.

I can confirm, this issue yet resolved.
The disqualification for three versions behind is not enabled as far as I know.
So, if your node doesn’t have failed audits in log, then two other possibilities will remain:

Working as designed. This version will allow you to run the storagenode, but it will not receive any traffic.
Perhaps design is not good, but it’s like this for the moment.

Any lower version of storagenode will not start either, it will crash with a message “too old version” in the logs and will be offline. More than 30 days in offline state - and it will be disqualified.

Can we check with satellite eu1. what was it? in this case?
Node ID is: 12nnNXUthnuz2gq2uotu2xcdouFonhhd54PcgXfuART2w4DQRay

because it shouldn’t happend so fast for a long time perfect node.

Im afraid that current disqualification method have some problems between distinguishing audit from time offline.

it kills a good node too fast in my opinion, the node was just having some time offline imho.

ideal for me would be an option to “Appeal” the disqualification, ( ideal a button in SNO dashboard) to ask sattelite to perform lastly failed audits once again.

  • Because whats audits function is, in my opinion, is to check files, right?. But currently dashboard says something else, as i showed in 1st post on screen: “Percentage of successful pings/comunication between the node & satelite”

i dont know if that disqualification was right or not, im saying it was not, and want to appeal please?

The best course of action would be to create a support ticket - Submit a request – Storj

You can submit the node ID along with your information and the StorJ team should reply directly to your disqualification query.

I sent a request to the team. Please, do not expect the quick answer. The team is busy and investigation is time consuming, and results are predictable - either timeouts or broken pieces, since you do not have failed audits in the logs and node is disqualified.

The tooltip is not exactly correct and I cannot imagine a better explanation. If you have it - please, suggest.

Tooltip for Audit score in the single satellite view
  • Percentage of healthy pieces of data on the node
  • Percentage of trust of the satellite to the node
  • own (please, specify)

0 voters

But I think the whole web-dashboard would be replaced by Multinode dashboard ([Tech Preview] Storage Node Multinode Dashboard and MND Dashboard - Payout Flow)

Yeah, no problem, Thx Alex.
Im just insisting to take topic seriously because few other ppl had similar problem and i saw the topic wasn’t solved completly.

My suspections, other than node did provide corrupted pieces, my suspection is the sattelite in some scenario may think the node is online (3 minutes after last contact or whatever it is?, i remember), and sends GET_AUDIT requests to node, which cannot be answered in time coz node is in fact offline. May happen if node goes online, for few minutes. and PC restarts because of some hardware problems, i had some problems with windows 10, and had few such starts of node that lasts only few minutes, im afraid sattelite didnt get too quick that node is offline again and send some GET_AUDIT. Again that happened only on eu1, and only that node, i have other nodes on this pc and they are fine.

Maybe something like:

A trust score representing the nodes response quality on random file access challenges

1 Like

The satellite requests the node and the node must answer, otherwise the audit considered as offline. This will affect an online score.
If node answered (so it’s definitely online), then the satellite will request a random piece, wait for 5 minutes until the node could provide the part of requested piece (a few kb) or until timeout. If node didn’t provide a piece, it’s placed into containment mode and will be requested for the same piece two more times. If node is unable to provide a piece anyway, the audit considered as failed and node went out of containment mode.

The second possibility, when the node answered on audit request, provided a piece, but it’s corrupted, the audit immediately considered as failed.