Storj - Speicher vermieten

Frieseba

Benutzer
Mitglied seit
27. Nov 2011
Beiträge
465
Punkte für Reaktionen
20
Punkte
24
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

Benutzer
Mitglied seit
05. Feb 2016
Beiträge
707
Punkte für Reaktionen
11
Punkte
38
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

Benutzer
Mitglied seit
27. Nov 2011
Beiträge
465
Punkte für Reaktionen
20
Punkte
24
Bei repair Ingress werden die Daten bei dir geparkt. Bei Egress selbige abgerufen. Meine, dass die dann auch etwas besser bezahlt sind
 

maalik

Benutzer
Mitglied seit
05. Feb 2016
Beiträge
707
Punkte für Reaktionen
11
Punkte
38
Okay, also wie meine Vermutung oben?
Finde repair ingress klingt erstmal so bisschen danach, dass bei mir Dateien repariert werden mussten.
 

Heidi

Benutzer
Mitglied seit
05. Aug 2019
Beiträge
291
Punkte für Reaktionen
50
Punkte
34
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

Benutzer
Mitglied seit
05. Feb 2016
Beiträge
707
Punkte für Reaktionen
11
Punkte
38
super, danke für die abermalige ausführung! :)
 

Nicky_1818

Benutzer
Mitglied seit
31. Jan 2014
Beiträge
90
Punkte für Reaktionen
4
Punkte
8
Habt Ihr das auch, dass seit 3 Tagen nahezu gar nichts mehr passiert? 20-30MB/Tag ist ja nix :confused:
 

maalik

Benutzer
Mitglied seit
05. Feb 2016
Beiträge
707
Punkte für Reaktionen
11
Punkte
38
Welche Version hast du denn installiert?
 

Nicky_1818

Benutzer
Mitglied seit
31. Jan 2014
Beiträge
90
Punkte für Reaktionen
4
Punkte
8
Aktuelle Version ist die 0.30.5. Kam auch noch keine eMail mit der üblichen update Aufforderung.
 

maalik

Benutzer
Mitglied seit
05. Feb 2016
Beiträge
707
Punkte für Reaktionen
11
Punkte
38
Jupp, ich würde auch erstmal updaten.
 

Nicky_1818

Benutzer
Mitglied seit
31. Jan 2014
Beiträge
90
Punkte für Reaktionen
4
Punkte
8
Hmmm... per watchtower sollte es doch eigentlich auch automatisch gehen? Naja, werd nachher mal das Update fahren.
 

maalik

Benutzer
Mitglied seit
05. Feb 2016
Beiträge
707
Punkte für Reaktionen
11
Punkte
38
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?

Rich (BBCode):
========== 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

Benutzer
Mitglied seit
31. Jan 2014
Beiträge
90
Punkte für Reaktionen
4
Punkte
8
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

Benutzer
Mitglied seit
13. Jan 2015
Beiträge
11
Punkte für Reaktionen
1
Punkte
3
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

Benutzer
Mitglied seit
17. Jul 2007
Beiträge
624
Punkte für Reaktionen
42
Punkte
48
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

Benutzer
Mitglied seit
31. Jan 2014
Beiträge
90
Punkte für Reaktionen
4
Punkte
8
Ja, Update hat tadellos geklappt. Alle anderen 3 Satelliten sind ja bei den üblichen 100%.
 

Heidi

Benutzer
Mitglied seit
05. Aug 2019
Beiträge
291
Punkte für Reaktionen
50
Punkte
34
@ Friseba: meine 4 Befehle, mit denen ich per shell den Knoten inspizieren kann sind:

Dashboard:
Rich (BBCode):
sudo docker exec -it storagenode /app/dashboard.sh
"storagenode" ist dabei der Name des Knoten, handelt sich hierbei um den Standardnamen.
Audit-Übersicht
Rich (BBCode):
sudo bash /volume1[oder 2 oder 3...]/[Ordner wo das sh-file drin liegt]/successrate.sh
Earningsübersicht
Rich (BBCode):
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
Rich (BBCode):
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

Benutzer
Mitglied seit
27. Nov 2011
Beiträge
465
Punkte für Reaktionen
20
Punkte
24
@ 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 :)
 


 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat