Meine Node läuft seit etwas mehr als 3 Jahren auf einem Synology NAS.
Seit etwa einem Monat ist mit aufgefallen das sich der Trash Speicher nicht mehr verändert.
Der Wert von monatlich genutztem Speicher und angezeigtem Speicherstand weicht auch ab. Das hab ich aber schon länger.
Jetzt hab ich vor ca 5 Tagen eine neue Festplatte in mein NAS gesteckt und dabei festgestellt das der Speicherplatz,den ich für Storj freigegeben habe, noch größer abweicht.
Monatlich Durchschnitt laut Dashboard ca 5.5TB
Laut Dashboard ca 8.3TB belegt
Laut NAS fast 10TB belegt.
Daraufhin hab ich Storj mal neugestartet hat aber auch nichts gebracht.
Was mir dabei auffiel, alle Werte des Speichers waren gleich nur der belegte Speicher ist durch den Neustart laut Dashboard um 0.2TB weniger gewesen. Jedesmal wenn ich Neustarte springt es auf diesen Wert zurück.
Das heiß, dass es mir auch aufgefallen ist. Aber nicht so ausgesprochen als auf Ihrem Knot.
Es gibt mehrere Gründe dafur:
Jede Woche gibt es einen Filter, den nur 90% genau ist. Der Filter beschreibt welche Dateien auf dem Knot gehören, und alle andere Dateien können entfernt werden.
Das Filewalker-Prozess ist zuständig für die Entfernung der Dateien die nicht gültig sind, aber das Prozess läuft mit zimlich niedriger Priorität. Insebesondern auch auf SMR-Festplattern.
Es ist auch möglich das sich noch Dateien dich dabefinden von abgestelten Satelliten.
Auf jeden fall hoffe ich das Storj sich etwas mehr kümmert um dieses ziemlich riesiges Unterschied zwischen die Nummern und die Realität. Auch auf Knoten die immer eingeschaltet sind und deswegen eigentlich jede Entfernung von Dateien der Kunden mitbekommen haben sollten.
Wie oben richtig angemerkt, ist es notwendig, dass Filewalker (Sie können in den Knotenprotokollen nach „walk“ suchen) und Garbage Collector (Sie können in den Knotenprotokollen nach „retain“ suchen) nicht ausfallen.
Es ist auch sinnvoll, nach Fehlern wie FATAL zu suchen; wenn es welche gibt, müssen Sie diese zuerst beseitigen (sie verhindern den erfolgreichen Abschluss von Filewalker und Garbage Collector).
Es ist bekannt, dass BTRFS für Speicherknoten langsam ist.
Ohne die Verwendung von SSD-Cache ist es für dieses Dateisystem ziemlich schwierig, Blöcke schnell zu lesen, sodass Filewalker und Garbage Collector mit Sicherheit Tage brauchen. Wenn der Vorgang unterbrochen wurde, beginnt er von vorne.
Bitte überprüfen Sie, ob Ihre Protokolle FATAL-Fehler enthalten.
du -s --si /volume2/storagenode1/storj/storage/blobs
und dann mit dem Ergebnis vergleichen
du -s --si --apparent-size /volume2/storagenode1/storj/storage/blobs
aber ich glaube nicht, dass es eine Frage der Clustergröße ist. Das Problem ist BTRFS ohne Cache. Hier können Sie nicht viel tun, außer die meisten BTRFS-Funktionen zu deaktivieren:
Fügen Sie entweder einen SSD-Cache hinzu oder migrieren Sie zu ext4.
Sieht aus das die Sektorgröße indertat 4K ist, wie standart ist in BTRFS. Aber kleinere Daten werden normalerweise ins Metadat ingebaut worden, damit sie nicht mehr Speicher belegen als sie am mindestens brauchen. Aber sieht es hier aus, dass das nicht so konfiguriert ist oder etwas (oder das 4K stimmt nicht).
Diese Datei sollte normalerweise inline auf dem Speicherplatter belegt sein in BTRFS. So, entwieder die Konfiguration ist abweichend oder das 4K stimmt nicht.
Weshalb diese Fragen, ich meine: was fügt es an den anwesenden Informationen zu? Sie sins vielleicht nicht dum, aber ich frage mich den Zweck der Fragen.
Kann nur der TS erklären.
Ja, aber sieht man nicht in den rapportierten Informationen. Nur wen man btrfs fi show {path} oder etwas Ähnliches einguckt. Viellecht gibt es auch ein Dashboard auf dem NAS, wo man das herausfinden kan. stat und ähnliche Tools, sind agnostisch für das unterliegende Dateienschema (BTRFS, ext4, NTFS…).
Synology verwendet mdraid und darüber hinaus ein modifiziertes BTRFS-Dateisystem. Daher ist die Paritätsstrafe die gleiche wie bei mdraid, zuzüglich der BTRFS-eigenen Verzögerungen aufgrund von Funktionen wie erweiterten Metadaten und COW (naja, und einer Struktur, die nicht für Millionen kleiner Dateien geeignet ist, die auch in Ordnern organisiert sind, nicht so, wie BTRFS es mag: On the impact of two-level directory structure for storing blobs).
