DSM 6.x und darunter Speicherauslastung unkorrekt angegeben

[Synchrotron]

Idomix habe ich früher auch empfohlen - zu DSM6. Inzwischen finden sich auf der Webseite von Dominik aber nur noch Teaser, die beschreiben, WAS da alles tolles eingerichtet wird, aber nicht mehr WIE.

Das kommt dann im Kurs, den es dort kostenpflichtig zu erwerben gibt. Ich habe kein Problem damit, dass er sein Wissen monetarisiert. Es ist mir aber keine Empfehlung mehr wert. Wer sucht, stößt ohnehin auf sein Angebot.

Das Buch empfehle ich hingegen. Es dient der eigenen Einarbeitung - gut so.

 

[schoeli]

Nachdem sich mein Problem doch nicht aufgelöst hatte (Speicherplatz wurde auch nach Tagen nicht freigegeben), hatte ich mich an den Synology-Support gewendet. Hier die Antwort:

(...)
Das Problem ist, dass Sie die Option "erweiterte Dateiintegrität" für den Ordner „XYZ“ aktiviert haben.

Dadurch wird die BTRFS-Option copy-on-write für den Ordner und alle Dateien darin aktiviert.

Damit der Speicherplatz frei wird, sichern Sie Ihre Daten aus dem Ordner mit HyperBackup.

Beachten Sie, dass ein einfaches verschieben auf ein anderes BTRFS-Volume oder in einen anderen Ordner mit deaktivierter Option nicht genügt, da die Option in den einzelnen Dateien und Ordner gespeichert wird und dann aktiviert bleibt.

Anschließend löschen Sie den Ordner und erstellen einen neuen Ordner ohne die Option beim erstellen zu aktivieren.

Dann stellen Sie Ihre Daten in der Ordner wieder her.

Dann sollte der Speicherplatz freigegeben werden. Beachten Sie dabei, dass dies eine Weile dauern kann und während dieser Zeit möglichst wenig I/O auf dem Volume sein sollte.
(...)

Wieder etwas dazugelernt, vor allem werde ich mir beim Anlegen neuer Gemeinsamer Ordner genau überlegen, ob ich unter "Erweitert" das Feld "Daten-Prüfsumme für erweiterte Dateiintegrität aktivieren" anklicke.

Sicher auch interessant für einige von euch!

Gruß
Schoeli

 

[plang.pl]

Hä
das hab ich ja noch nie gehört.
Berichte mal, ob das bei dir tatsächlich funzt

 

[Benie]

Wieder etwas dazugelernt, vor allem werde ich mir beim Anlegen neuer Gemeinsamer Ordner genau überlegen, ob ich unter "Erweitert" das Feld "Daten-Prüfsumme für erweiterte Dateiintegrität aktivieren" anklicke.

Da stellt sich mir die Frage, warum dann überhaupt Btrfs, wenn man diese Funktion abschaltet, verliert Btrfs seine Haupteigenschaften, zb. Schutz vor Bit-rot, wenn keine Dateiintegrität mehr vorhanden ist, ist auch keine Reperatur der Daten im Fall von zb. Bit-rot möglich.

Ich habe für alle meine Freigegebenen Ordner die Dateiintegrität aktiviert, und kann bisher dieses Phänomen daß Speicherplatz nicht mehr freigegeben wird nicht wirklich feststellen.
Man sollte halt schon genau abwägen, wann man es nicht aktiviert. Zb. bei Dateien der Surveilance Station die eh stetig wechseln ist es völlig unnötig.
Mit Btrfs lassen sich zb. aufgrund der vorhandenen Dateiintegrität unzählig viele Snapshots erstellen bei wenigem Platzverbrauch.
Für eine VM Umgebung ist dies auch nicht gerade von Vorteil, da diese hierbei ausgebremst wird.

 

[schoeli]

So, ich habe das nun so umgesetzt, wie vom Support beschrieben. Ergebnis: hat funktioniert!
Die Speicheranzeige stimmt nun wieder (3 TB weniger als zuvor angezeigt), binnen kürzester Zeit war alles wieder korrekt. Dennoch denke ich, dass man sich sehr genau überlegen sollte, in welchen Fällen man einen gemeinsamen Ordner anlegt, ohne das Feld "Daten-Prüfsumme für erweiterte Dateiintegrität aktivieren" zu aktivieren.

 

[Der Heidjer]

Ja, vielen Dank für diese Tipps, erstmal läuft's ja nun und ich konnte alles speichern.

 

[himitsu]

Und ich dachte das berechnet nur eine Prüfsumme für die Dateien, wobei dadurch das Schreiben ausgebremst wird.
Damit man auf Dateiebene später Datenfehler gezielter finden kann.

Zum Reparieren müssten ja auch noch irgendwelche Reparaturdaten (belegen natürlich mehr Speicherplatz) abgelegt werden.



Das mit den Prüfsummen hatte ich mir selber gebastelt, mit einem zeitgezeuertem Script, welches einen Hash für jede Datei berechnet und in einer Datei ablegt, welches sich bei Bedarf prüfen lässt.
Synology selber warnt ja vor dem Datenintigritätszeugs, wenn man es aktivieren will.

HyperBackup

Bei ähnlichen Problemen, mit Metadaten und Dergleichen, verwende ich gern auch eine unkomprimierte ZIP (packen, löschen und wieder entpacken). Geht schneller als vieles Anderes.

 

[geimist]

Zum Reparieren müssten ja auch noch irgendwelche Reparaturdaten (belegen natürlich mehr Speicherplatz) abgelegt werden.

Ich habe gerade keine Quelle, aber deshalb galt es mal, das in einen Basis-Volume so nur Fehler erkannt und erst in einen RAID auch automatisch behoben werden können.

 

[Benie]

Da liegst Du genau richtig. Beim Daten-Scrubbing berechnet das Dateisystem die Prüfsumme neu und vergleicht diese mit der zuvor gespeicherten Prüfsumme.
Stellt das System dabei eine Beschädigung der Daten fest, versucht es diese aus den Daten des vorhandenen Raids, welches im Normalfall bereits für die notwendige Datenkonsistenz gesorgt hat,wieder zu reparieren. D.h. es werden zumindest deshalb keine zusätzlichen Datendateien gespeichert.

Eine Reperatur wird ausschließlich aus den bereits im Raid vorhandenen Daten anhand der Prüfsummen berechnet und wieder hergestellt. (Prüfsummen, welche mit Sicherheit im Gegensatz zu den Daten nur wenigen Speicherbedarf haben)

Da es sich hierbei nur um die zusätzliche Speicherung der Prüfsummen handelt, deshalb kann ich mir eigentlich nicht vorstellen, daß solch riesige Datenmengen wie 3 TB zustande kommen. Wäre natürlich interessant, warum die Datenmenge bei @schoeli so deutlich zurückgegangen ist.
Wenn ich mein Backup welches mit rsync auf eine Zweite DS ohne Raid gesynct wird, so habe ich hier so gut wie keinen Unterschied in den Datenmengen obwohl auf der Quell DS die Datenintegrität für die Ordner eingerichtet ist und auf der Ziel DS (Backup) nicht..

 

[schoeli]

Bei mir war das Problem, dass auf Grund einer fehlerhaften Konfiguration von ecoDMS ein vollständiges Backup quasi in einer Endlosschleife lief und anstatt ca. 15 GB dann rund 3 TB anwuchsen und der Sicherungsvorgang - als er entdeckt wurde - manuell beendet werden musste. Der daraus resultierende Datenmüll (ca. 3 TB) wurde dann von mir gelöscht (auch aus dem Papierkorb), dennoch wurden wie von mir beschrieben die 3 TB immer noch als belegter Speicher angezeigt. Mittlerweile ist wie gesagt wieder alles gut (auch ecoDMS wurde wieder korrekt konfiguriert).

 

[geimist]

Dennoch kann ich mir nicht vorstellen, dass es etwas mit den Prüfsummen zu tun hat.
Ich bin jetzt nicht nochmal den Thread durchgegangen, aber gerade bei Btrfs gibt es ja einen Zeitplan für die "Speicherplatzrückgewinnung", welche explizit ausgeführt werden muss. Und hatten wir schon über Snapshots geredet?

 

[himitsu]

Jupp, die winzigen Prüfsummen können es kaum sein.
Maximal kurzzeitig die alten Daten, bis die neue/geänderte Datei gespeichert/geschlossen und neu berechnet wurde.


OK stimmt, daran nicht gedacht, also das RAID selber als Reparatur-Quelle zu betrachten.

Wenn eine bestimmte Platte kaputt ist, und man die Restlichen als "Vertrauenswürdig erachtet, dann lässt sich auf Ebene des RAID das reparieren (neuberechnen ... ist ja bei der Parität nur ein Austausch der Variablen, um die Rechnung umzukehren).

Wenn in "irgendeiner" Platte, oder Mehreren ein Fehler vorkommt und je jeweilige Platte nicht selber sagt "ich war's", dann weiß das RAID nur, dass die Parität nicht stimmt und kann womötlich nichts reparieren.
Bei RAID6/SHR2 gäbe es noch eine zweite Parität mit der man teilweise gegenprüfen kann.

Liegt dort zufällig eine dieser gehashten Dateien, dann ließe sich prüfen auf welcher Platte der Fehler ist, bzw. welchen Platten/Sektoren man am meisten trauen kann.


Es kommt auch drauf an wie und wo die Hashs gespeichert werden.
Bei 2.000.000 Dateien können das dann 65 MB sein (im Dateisystem an der Datei), oder viellecht über 30 GB (in einer Liste aus Pfad+Dateiname mit Hash) oder auch nur 8 MB als CRC32 an jeder Datei.


Hatte eher an sowas, wie bei ZIP/RAR/... gedacht, wo man x% zusätzliche Reparaturdaten mit abspeichern kann.
Es gibt auch viele Dateiformate, welche in sich auch nochmal Hashs besitzen. (wäre Intelligent sowas mit auszuwerten)




Was Hyper Backup Vault und AB4B machen, würde ich auch gern mal wissen.
Hatte auch mal so unglücklich gespeicherte Backups.
Das Speichern geht noch recht schnell (auch wenn es eigentlich langsam ist), aber das Löschen von Versionen .... also das ist pervers langsam.