Storj - Speicher vermieten

[Frieseba]

Heidi hat suich im Beitrag 147 die Mühe gemacht, Repair, Ingress und Egress genauer zu erklären. Da findest du alles. Ja, repair ist gerade hoch.

 

[maalik]

Moin Frieseba, ja, den Beitrag kenne ich. Kam ja sogar auf meine Frage damals als Antwort. Dennoch ist mir die Unterscheidung von ingress/egress bei repair eben noch nicht genau verständlich.

 

[Frieseba]

Bei repair Ingress werden die Daten bei dir geparkt. Bei Egress selbige abgerufen. Meine, dass die dann auch etwas besser bezahlt sind

 

[maalik]

Okay, also wie meine Vermutung oben?
Finde repair ingress klingt erstmal so bisschen danach, dass bei mir Dateien repariert werden mussten.

 

[Heidi]

Hallo Maalik,

wie Frieseba beschrieben hat: Repair Egress heißt, ein anderer Nutzer hat seinen Knoten geschlossen. Die Daten liegen immer Redundant auf mehreren Knoten. Wenn dessen Daten noch auf deinem Knoten lagen, dann zieht der Satellit die Daten von dir und parkt sie auf einem anderen, neuen Knoten. Dieser Repair Prozess wird dann auf deinem Knoten als Repair-Egress verbucht und auf dem neuen anderen Knoten als Repair ingress.

Entgegen der Aussage von Frieseba bekommst du als repair-uploader weniger für den egress, als wenn ein Nutzer seine Daten regulär von deinem knoten anfordert. Um genauzu sein bekommst du für den repair die Hälfte (nämlich 10$/TB). Siehe https://storj.io/blog/2019/01/sharing-storage-space-for-fun-and-profit

Repair bandwidth - storage nodes are paid for the egress bandwidth used when satellites download pieces of files from storage nodes as part of the repair process. Payments will be made to storage node operators at $10 per TB. These bandwidth payments to storage node operators are for all data downloaded by Satellites as part of the process to repair data that is lost due to node churn.Note that Satellites download pieces from multiple storage nodes, then recreate missing pieces, and upload the new pieces to other statistically uncorrelated, high-reputation nodes. Storage nodes are not responsible for actual data repair. For more information on the details of file repair, check out the white paper.

 

[maalik]

super, danke für die abermalige ausführung!

 

[Nicky_1818]

Habt Ihr das auch, dass seit 3 Tagen nahezu gar nichts mehr passiert? 20-30MB/Tag ist ja nix

 

[maalik]

Welche Version hast du denn installiert?

 

[Nicky_1818]

Aktuelle Version ist die 0.30.5. Kam auch noch keine eMail mit der üblichen update Aufforderung.

 

[Frieseba]

v 31.12 ist gerade aktuell

 

[maalik]

Jupp, ich würde auch erstmal updaten.

 

[Nicky_1818]

Hmmm... per watchtower sollte es doch eigentlich auch automatisch gehen? Naja, werd nachher mal das Update fahren.

 

[Frieseba]

Möchte gerne meine Success Rate auslesen. Habe diese Anleitung gefunden und komme gerade echt nicht weiter!
https://github.com/ReneSmeekes/storj_success_rate
path to successrate.sh folder und path to the log file folder ?? Kann die bei mir im Dockerordner nicht finden. Oder event bin ich langsam zu alt

 

[maalik]

Wenn du die offizielle Anleitung zum Aufsetzen befolgt hast, dann sieht der Befehl so aus:

sh ./successrate.sh storagenode

storagenode musst du halt anpassen an den Containernamen.

Aber spannend. Habe folgende Werte. Warum so eine schlechte Upload Success Rate?

========== AUDIT =============
Successful:           799
Recoverable failed:   0
Unrecoverable failed: 0
Success Rate Min:     100.000%
Success Rate Max:     100.000%
========== DOWNLOAD ==========
Successful:           6970
Failed:               3
Success Rate:         99.957%
========== UPLOAD ============
Successful:           10390
Rejected:             0
Failed:               8542
Acceptance Rate:      100.000%
Success Rate:         54.881%
========== REPAIR DOWNLOAD ===
Successful:           1
Failed:               0
Success Rate:         100.000%
========== REPAIR UPLOAD =====
Successful:           1140
Failed:               1104
Success Rate:         50.802%

 

[Nicky_1818]

Also irgendwie ist gerade der Wurm drinnen.
Ich habe per Hand das update angeschoben, obwohl dies ja eigentlich der "watchtower" machen sollte.
Jetzt habe ich wieder die üblichen up- und downloads. Auf dem Dashboard habe ich aber auf einmal für den Satelliten "europe-west-1.tardigrade.io:7777" einen Uptime-Check von 1,2%. Alle Anderen haben 100%. Wie sieht das bei euch aus?

 

[harun]

Der Uptime Check ist bei mir überall auf 100%. Würde ich aber momentan nicht sonderlich viel drauf geben. Die momentane Art der Überprüfung funktioniert wohl nicht richtig und wird derzeit überarbeitet. Uptime ist derzeit auch kein Grund zur Disqualifikation.

 

[kev.lin]

Ich habe vorgestern auf die v31.12 geupdatet. Die Satelliten haben alle eine Uptime von >=99,9%.
Hat das Update auf v31.12 bei Dir denn geklappt?

 

[Nicky_1818]

Ja, Update hat tadellos geklappt. Alle anderen 3 Satelliten sind ja bei den üblichen 100%.

 

[Heidi]

@ Friseba: meine 4 Befehle, mit denen ich per shell den Knoten inspizieren kann sind:

Dashboard:

sudo docker exec -it storagenode /app/dashboard.sh

"storagenode" ist dabei der Name des Knoten, handelt sich hierbei um den Standardnamen.
Audit-Übersicht

sudo bash /volume1[oder 2 oder 3...]/[Ordner wo das sh-file drin liegt]/successrate.sh

Earningsübersicht

sudo python /volume[oder 2 oder 3...]/[Ordner wo das sh-file drin liegt]j/earnings.py /volume1/[Ordner wo der Knoten liegt]/storage/

earnings rückblicken

sudo python /volume1/Storj/earnings.py /volume1/Storj/storage 2020-01

@maalik: Die schlechte Upload-Successrate kommt 100% von deiner Internetleitung. Sobald jemand eine File vom netzwerk runterlädt, wird diese bei allen Knoten, auf denen sie redundant liegt, angefragt. Dann startet ein Wettrennen. Wer zuerst hochgeladen hat, der gewinnt. Kriegt Geld. Und kriegt ne gute Reputation. So wird garantiert, dass immer schneller Knoten bevorzugt werden.
Wer weiß, vielleicht führen die noch ein 2-Klassen System ein, so wie Amazon. Dort wird auch unterschieden zwischen teurem high-speed cloud speicher und billigerem, langsamen selten-zugriff-Backup-spiecher.

 

[Frieseba]

@ Heidi: Vielen Dank für die Befehle. Nun habe ich auf allen Sats min 100 Audits und es läuft Besser als TV am Abend im Docker die up- und downloads zu beobachten