# The hard drive is full because storj probably hasn't deleted anything anymore **URL:** \ **Category:** troubleshooting\ **Tags:** auf-deutsch, hardware\ **Created:** [March 13, 2024, 8:11pm UTC](https://forum.storj.io/t/the-hard-drive-is-full-because-storj-probably-hasnt-deleted-anything-anymore/25510 "2024-03-13T20:11:17Z")\ **Posts on this page:** 20\ **Page:** 3
**Author:** ![daki82](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/daki82/32/1128_2.png) [@daki82](https://forum.storj.io/u/daki82)\ **Post date:** [March 17, 2024, 3:17pm UTC](https://forum.storj.io/t/the-hard-drive-is-full-because-storj-probably-hasnt-deleted-anything-anymore/25510/41 "2024-03-17T15:17:37Z")
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. ---
**Author:** ![Muntermacher](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/muntermacher/32/11670_2.png) [@Muntermacher](https://forum.storj.io/u/Muntermacher)\ **Post date:** [March 17, 2024, 6:18pm UTC](https://forum.storj.io/t/the-hard-drive-is-full-because-storj-probably-hasnt-deleted-anything-anymore/25510/42 "2024-03-17T18:18:04Z")
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. ---
**Author:** ![daki82](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/daki82/32/1128_2.png) [@daki82](https://forum.storj.io/u/daki82)\ **Post date:** [March 17, 2024, 7:17pm UTC](https://forum.storj.io/t/the-hard-drive-is-full-because-storj-probably-hasnt-deleted-anything-anymore/25510/43 "2024-03-17T19:17:55Z")
> [@Muntermacher](#): > > Nun läuft gerade eine Analyse, die ja schon recht viel Zeit braucht. Ja, bei 26% wirds höchste zeit zu defragmentieren. alles über 5% ist schon zu viel. > [@Muntermacher](#): > > Aktuell lief die Node schon mal über 24 Stunden und ohne eine “fatal” Meldung. 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? ---
**Author:** ![Muntermacher](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/muntermacher/32/11670_2.png) [@Muntermacher](https://forum.storj.io/u/Muntermacher)\ **Post date:** [March 17, 2024, 7:49pm UTC](https://forum.storj.io/t/the-hard-drive-is-full-because-storj-probably-hasnt-deleted-anything-anymore/25510/44 "2024-03-17T19:49:41Z")
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. ---
**Author:** ![daki82](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/daki82/32/1128_2.png) [@daki82](https://forum.storj.io/u/daki82)\ **Post date:** [March 17, 2024, 7:55pm UTC](https://forum.storj.io/t/the-hard-drive-is-full-because-storj-probably-hasnt-deleted-anything-anymore/25510/45 "2024-03-17T19:55:44Z")
auch so, das uptimerobot den absturz erkennt?? ---
**Author:** ![Muntermacher](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/muntermacher/32/11670_2.png) [@Muntermacher](https://forum.storj.io/u/Muntermacher)\ **Post date:** [March 17, 2024, 8:15pm UTC](https://forum.storj.io/t/the-hard-drive-is-full-because-storj-probably-hasnt-deleted-anything-anymore/25510/46 "2024-03-17T20:15:34Z")
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. ---
**Author:** ![daki82](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/daki82/32/1128_2.png) [@daki82](https://forum.storj.io/u/daki82)\ **Post date:** [March 17, 2024, 8:18pm UTC](https://forum.storj.io/t/the-hard-drive-is-full-because-storj-probably-hasnt-deleted-anything-anymore/25510/47 "2024-03-17T20:18:29Z")
Kurz gesagt: die zeit nach der der knoten neu startet ist größer als der check Intervall vom uptimerobot. Optimal. ---
**Author:** ![Muntermacher](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/muntermacher/32/11670_2.png) [@Muntermacher](https://forum.storj.io/u/Muntermacher)\ **Post date:** [March 17, 2024, 8:30pm UTC](https://forum.storj.io/t/the-hard-drive-is-full-because-storj-probably-hasnt-deleted-anything-anymore/25510/48 "2024-03-17T20:30:26Z")
Ja, tagsüber hilft das eine mehr und nachts dann das andere 🙂 ---
**Author:** ![daki82](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/daki82/32/1128_2.png) [@daki82](https://forum.storj.io/u/daki82)\ **Post date:** [March 17, 2024, 9:06pm UTC](https://forum.storj.io/t/the-hard-drive-is-full-because-storj-probably-hasnt-deleted-anything-anymore/25510/49 "2024-03-17T21:06:11Z")
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. ---
**Author:** ![Muntermacher](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/muntermacher/32/11670_2.png) [@Muntermacher](https://forum.storj.io/u/Muntermacher)\ **Post date:** [March 18, 2024, 3:32pm UTC](https://forum.storj.io/t/the-hard-drive-is-full-because-storj-probably-hasnt-deleted-anything-anymore/25510/50 "2024-03-18T15:32:19Z")
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](http://eu1.storj.io): operation was canceled”, “errorVerbose”: "untrusted: unable to get signee: trust: rpc: tcp connector failed: rpc: dial tcp: lookup [eu1.storj.io](http://eu1.storj.io): operation was canceled\n\tstorj.io/storj/storagenode/piecestore.(\*Endpoint).VerifyOrderLimitSignature:140\n ---
**Author:** ![Muntermacher](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/muntermacher/32/11670_2.png) [@Muntermacher](https://forum.storj.io/u/Muntermacher)\ **Post date:** [March 18, 2024, 7:56pm UTC](https://forum.storj.io/t/the-hard-drive-is-full-because-storj-probably-hasnt-deleted-anything-anymore/25510/51 "2024-03-18T19:56:02Z")
Ist es eigentlich normal, dass die Dateien in blobs schreibgeschützt sind? ---
**Author:** ![daki82](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/daki82/32/1128_2.png) [@daki82](https://forum.storj.io/u/daki82)\ **Post date:** [March 18, 2024, 8:26pm UTC](https://forum.storj.io/t/the-hard-drive-is-full-because-storj-probably-hasnt-deleted-anything-anymore/25510/52 "2024-03-18T20:26:49Z")
JA, die werden nicht geändert, nur gelöscht und neu geschrieben. Das ist zu ihrem Schutz vor versehentlicher Änderung. ---
**Author:** ![Muntermacher](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/muntermacher/32/11670_2.png) [@Muntermacher](https://forum.storj.io/u/Muntermacher)\ **Post date:** [March 18, 2024, 8:41pm UTC](https://forum.storj.io/t/the-hard-drive-is-full-because-storj-probably-hasnt-deleted-anything-anymore/25510/53 "2024-03-18T20:41:33Z")
gut zu wissen. Danke. ---
**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\ **Post date:** [March 19, 2024, 2:57am UTC](https://forum.storj.io/t/the-hard-drive-is-full-because-storj-probably-hasnt-deleted-anything-anymore/25510/54 "2024-03-19T02:57:08Z")
dieser Fehler: > [@Muntermacher](#): > > operation was canceled 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. ---
**Author:** ![Muntermacher](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/muntermacher/32/11670_2.png) [@Muntermacher](https://forum.storj.io/u/Muntermacher)\ **Post date:** [March 19, 2024, 2:56pm UTC](https://forum.storj.io/t/the-hard-drive-is-full-because-storj-probably-hasnt-deleted-anything-anymore/25510/55 "2024-03-19T14:56:00Z")
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. ---
**Author:** ![daki82](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/daki82/32/1128_2.png) [@daki82](https://forum.storj.io/u/daki82)\ **Post date:** [March 19, 2024, 6:35pm UTC](https://forum.storj.io/t/the-hard-drive-is-full-because-storj-probably-hasnt-deleted-anything-anymore/25510/56 "2024-03-19T18:35:26Z")
> [@Muntermacher](#): > > 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 Das sollte sich erledigt haben wenn die filewalker wieder richtig funktionieren. Die indexierung der dateiinhalte ist ja aus für das laufwerk? ---
**Author:** ![Muntermacher](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/muntermacher/32/11670_2.png) [@Muntermacher](https://forum.storj.io/u/Muntermacher)\ **Post date:** [March 19, 2024, 8:22pm UTC](https://forum.storj.io/t/the-hard-drive-is-full-because-storj-probably-hasnt-deleted-anything-anymore/25510/57 "2024-03-19T20:22:17Z")
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. ---
**Author:** ![Muntermacher](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/muntermacher/32/11670_2.png) [@Muntermacher](https://forum.storj.io/u/Muntermacher)\ **Post date:** [March 19, 2024, 8:40pm UTC](https://forum.storj.io/t/the-hard-drive-is-full-because-storj-probably-hasnt-deleted-anything-anymore/25510/58 "2024-03-19T20:40:30Z")
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? ---
**Author:** ![daki82](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/daki82/32/1128_2.png) [@daki82](https://forum.storj.io/u/daki82)\ **Post date:** [March 19, 2024, 9:50pm UTC](https://forum.storj.io/t/the-hard-drive-is-full-because-storj-probably-hasnt-deleted-anything-anymore/25510/59 "2024-03-19T21:50:26Z")
> [@daki82](#): > > wenn die folder nur noch 4 sind, kannst du den temp ordner vom node mal posten, ob da dateien älter 3 tage drin sind. wie schauts im temp ordner vom node aus? > [@Muntermacher](#): > > , dass Filewalker nicht ordentlich läuft, weil die Festplatte randvoll ist und immer zu 100% im Zugriff. Die Festplatte wird nicht bereinigt, weil Filewalker nicht tut was er muss. Da drehen wir uns doch im Kreis. 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. ---
**Author:** ![Alexey](https://storj.bcdn.literatehosting.com/user_avatar/forum.storj.io/alexey/32/41_2.png) [@Alexey](https://forum.storj.io/u/Alexey)\ **Post date:** [March 20, 2024, 4:57am UTC](https://forum.storj.io/t/the-hard-drive-is-full-because-storj-probably-hasnt-deleted-anything-anymore/25510/60 "2024-03-20T04:57:01Z")
> [@Muntermacher](#): > > Kann man den auch anstoßen oder höher priorisieren? Ja, Sie können die Leistung aller Filewalker verbessern, indem Sie den „Lazy“-Modus deaktivieren: > [@Filewalker error](https://forum.storj.io/t/filewalker-error/24836/2): > > This is mean that the disk has a great latency and prevent the filewalker to finish its work. You may try to disable the lazy filewalker to allow it to run with a normal priority pieces.enable-lazy-filewalker: false save the config and restart the node. You may also use it as an argument after the image name in your docker run command: docker run -d ... ... storjlabs/storagenode:latest \ --pieces.enable-lazy-filewalker="false" [Previous page](https://forum.storj.io/t/the-hard-drive-is-full-because-storj-probably-hasnt-deleted-anything-anymore/25510.md?page=2) [Next page](https://forum.storj.io/t/the-hard-drive-is-full-because-storj-probably-hasnt-deleted-anything-anymore/25510.md?page=4)