Das freigeben dauert auch länger und soll nur vor weiterem speichern schützen. Da die platte ja voll ist. Nur trash wird gelöscht, und der freie platz nicht weiter befüllt. Das ist auch normal so. Die daten wolln wir ja behalten.
Das entlasted den node, so das der timeout error nicht so oft auftritt. Logisch.
Wenn irgendwann der overused platz angezeigt wird,
Sollte die Speicherplatz variable wieder angepasst werden.
Auch muss er warscheinlich dringend defragmentiert werden. Das kann aber erst geschehen sobald die datenbank ok ist und kann auch während dem node betrieb erfolgen. Dauert aber ein paar wochen.
ja, als ich das letzte Mal geschaut hatte, waren 26% fragmentiert. Nun läuft gerade eine Analyse, die ja schon recht viel Zeit braucht.
Im Moment schaue ich immer mal wieder in die storagenode.log und schaue, dass ich da noch Missstände beseitige.
Aktuell lief die Node schon mal über 24 Stunden und ohne eine “fatal” Meldung.
Auch das Beenden und Starten des Dienstes läuft jetzt wieder reibungslos, was zwischendurch auch schon Probleme machte.
Ich warte jetzt noch ab, ob alle Datenbanken okay sind.
Ja, bei 26% wirds höchste zeit zu defragmentieren. alles über 5% ist schon zu viel.
Er muss ja auch grede keine eingehenden daten bearbeiten.
Nachdem alles wieder normal und defragmentiert ist, kann nochmal auf die timeouts geachtet werden.
Hast du uptimerobot oder ähnliches?
ja, nutze Uptime-Robot und bin da auch sehr zufrieden mit und habe den Dienst der Node auch so eingerichtet, dass er sich nach einem Absturz selber wieder startet, was auch gut funktioniert.
ja, der Port wird überwacht und ist ja nach Absturz nicht mehr offen. Ich bekomme dann direkt Benachrichtigung/Mail. Überwache einen weiteren Port auch damit.
Bei mir hilft es den check und neustart interval um die 15 min zu haben. So das normale updates und windows neustarts nicht so auffallen. Da diese idr kürzer sind.
Außerdem kann das handy bei mir gerne über nacht automatisch in den nicht stören modus gehn. Dann seh ich die uptimerobot meldung ja morgens. Und die famlie kann ruhig schlafen.
Ist sowas normal? Kommt das immer mal wieder vor oder ist da ein grundlegendes Problem:
2024-03-18T16:26:30+01:00 ERROR piecestore download failed {“Piece ID”: “V74DJVWS76RLS6S3DTYWVX5A5DC6TQWSEO3MX6Q467LU4W2EBPPQ”, “Satellite ID”: “12L9ZFwhzVpuEKMUNUqkaTLGzwY9G24tbiigLiXpmZWKwmcNDDs”, “Action”: “GET”, “Remote Address”: “103.214.68.73:48572”, “error”: “untrusted: unable to get signee: trust: rpc: tcp connector failed: rpc: dial tcp: lookup eu1.storj.io: operation was canceled”, “errorVerbose”: "untrusted: unable to get signee: trust: rpc: tcp connector failed: rpc: dial tcp: lookup eu1.storj.io: operation was canceled\n\tstorj.io/storj/storagenode/piecestore.(*Endpoint).VerifyOrderLimitSignature:140\n
bedeutet, dass der Client den Download von Ihrem Knoten abgebrochen hat, weil er bereits die erforderliche Mindestanzahl an Teilen von anderen Knoten heruntergeladen hatte und Ihr Knoten langsamer war.
Kurz gesagt, es ist normal.
Durch eure vielen guten Hinweise, habe ich wieder etwas Motivation gewonnen und nun mal als erstes meine Datenbanken auf die SSD Festplatte umziehen lassen. Nun beobachte ich erstmal weiter.
Dass aber von mir mehr als 12 TB zur Verfügung gestellt werden und komplett belegt sind und ich nur für 6,5 TB entlohnt werde ist für mich kein haltbarer Zustand. Man darf Daten nicht selber löschen, der filewalker soll es tun und tut es nicht.
Wenn es da keine Befehle gibt, die da weiter helfen, werde ich eher oder später wohl doch aussteigen.
Danke auch nochmal für diesen Hinweis. Die Indiziierung ist aus. Habe es aber lieber nochmal bei der Gelegenheit geprüft.
Aktuell läuft der Knoten erst 5 Stunden. Im .log kein “fatal” zu finden. “error” in den letzten 3 Stunden gar keiner. Davor nur 3 mal unbedenkliche Abbrüche (weil andere wohl schneller waren). Die Suche nach “database” gab nur den einen Treffer, wo die Versionsnummer angegeben wird also ist da aktuell auch nichts “locked” oder ähnliches.
mit “walk” habe ich nach über 5 Stunden in der .log nichts gefunden. Wann rührt sich denn der der filewalker? Kann man den auch anstoßen oder höher priorisieren?
ja, da spielt aber auch die fragmentierung eine rolle. zusammen mit den datenbanken und ein paar weniger relevanten sachen.
Sobald der node genug freien platz hat (real auf der platte) könnte man mal chkdsk machen und defragmentieren.
was macht denn die analyse? wieviel is denn fragmentiert?
Auch ist der MFT mit ~64gb sehr groß, als letztes mittel sollte der auch defragmentiert werden.
