DSM 6.x und darunter Snapshot Recovery nicht möglich - BTRFS

[Tobintax]

Hallo zusammen,

ich habe an meiner DS1815+ ein Verhalten festgestellt, dass ich gerne verifizieren lassen würde.

Wenn ein Shared Folder der einen Snapshot enthält auf einem BTRFS Volume gelöscht wird, bleiben die Snapshots erhalten. Jedoch kann der Snapshot nicht mehr über den Gui (Snapshot Replication Gui) verwaltet (gelöscht, restored) werden.
Die Frage ist, wie dieser Snapshot weiter über den GUI gemanaged werden kann. Über die Command Line ist mir das klar, kann aber nicht Sinn der Sache sein.

Es wäre nett wenn jemand auf seiner Syno das ganze reproduzieren könnte:

1. Erstellen eines BTRFS Volumes mit 15 GB.
2. Einen Shared Folder auf diesem BTRFS Volume erstellen
3. 10 GB Daten in diesen neuen Shared Folder kopieren.
4. Einen Snapshot über den Snapshot Replication Gui erstellen
5. Die 10 GB Daten in dem Shared Folder löschen

Die Größe des Volumes ansehen. Es sollten nun 10 GB Used sein, da der Snapshot diesen Platz benötigt. Soweit so gut.

6. Den Shared Folder löschen.

Ergebnis: Auf dem Volume sind weiterhin 10 GB Space belegt. Der Snapshot benötigt weiterhin diesen Platz. Der zuvor erstellte Snapshot kann über den GUI nicht gelöscht werden.

Ist das bei euch auch so?

Grundsätzlich ist das in Ordnung, so bestände die Möglichkeit den kompletten Shared Folder zu restoren. Nur dass das über den GUI nach dem löschen des Shared Folder's m. E. nicht mehr möglich ist, ist nicht optimal....

Danke im voraus

Martin

 

[LeeRoy]

Hi Martin,
bin auf Deinen Thread gestoßen.

Ich hab das eben unter DSM 6.1 mal nachgestellt. Nach dem Löschen des Shared Folders sind bei mir sofort sowohl der Shared Folder als auch seine Snapshots weg. Auch unter /volume1/@sharesnap ist nichts mehr sichtbar bzw. mit btrfs su list /volume1 taucht kein Snapshot mehr von dem ehem. Shared Folder auf.

Wie kommst Du darauf, dass der Snapshot noch existiert ?

 

[Tobintax]

Hi LeeRoy,

danke dass Du es getestet hast. Ich habe schon gar nicht mehr an diesen Thread gedacht.
Ich konnte damals den Snapshot noch unter @sharesnap sehen. Jedoch wurde dieser ca. 30 Minuten nach Löschung des Folders gelöscht. Woher die Verzögerung kam, kann ich mir nicht erklären.

Habe es mit DSM6.1RC nochmal nachgestellt, da ist es nicht mehr aufgetreten. Ist also aus meiner Sicht erledigt.

Danke dir!

Gruss

Martin

 

[LeeRoy]

BTRFS, ZFS oder NetApp's WAFL schreiben Daten immer an eine neue, freie Stelle. Deshalb entsteht dem System kein Mehraufwand wenn Snapshots bestehen. Es "vergißt" einfach nicht, dass die Blöcke, die im aktiven FS gelöscht/geändert sind, noch von jemanden referenziert werden (ähnlich hard links). Wenn niemand mehr (weder aktives FS, clone oder snapshot) auf einen Block zeigt, wird er wieder dem Pool freier Blöcke zugeführt. Das passiert aber nicht sofort sondern nachgelagert durch scanner. Je nach Last kann das also dauern, bis nach dem Löschen die freigewordene Kapazität wieder also solche sichtbar wird.
Ich kann mir auch vorstellen, dass da in BTRFS noch viel Luft für Optimierung ist und da Synology ja mit Kernel Versionen relativ konservativ ist, sind wir da sicher mit DSM nicht auf dem letzten Stand.
Gruß
Günter

 

[Tobintax]

Das kenne ich von netapp nicht. Da dauert das einen Fingerschnipp. Meine Erfahrungen mit btrfs würde ich jedoch als Beginner bezeichnen. Gut möglich dass in btrfs noch Optimierungspotential steckt.

 

[AndiHeitzer]

Das ist ganz normal so.

Wenn ich, egal wo, einen großen Haufen Daten lösche, dann wandert der für mich unsichtbar ein einen @tmp des Volumes.
Das kann ich nur auf der Konsole so nachgucken. Und nein, einen Papierkorb nutze ich hier nicht.

Das Verhalten mag daran liegen, dass das DSM diese Files erst so nach und nach physikalisch entfernt. Warum auch immer.
In meiner Anfangszeit mit Syno "löste" ich dies durch einen Reboot, was natürlich auch nicht im Sinne des Erfinders ist/war. Aber nur so bin ich damals dahintergestiegen.

 

[LeeRoy]

NetApp ist ja auch der "Godfather of COW" - WAFL seit 1992.
Da ist BTRFS von der Bedienbarkeit her Lichtjahre entfernt.
Wenn man Files (oder Shared Folder = Subvolumes) oder Snapshots löscht, werden die Blöcke dem Free Pool zugeführt. Das geschieht über Scanner im Hintergrund. Bei hoher Last wird sowas auch mal hinten angestellt und so kann es von Fall zu Fall etwas dauern, bis die freie Kapazität das widerspiegelt. Ich denke hier wird BTRFS auch mit jeder Kernelversion etwas optimiert.

 

[Tobintax]

Das ist ganz normal so.

Wenn ich, egal wo, einen großen Haufen Daten lösche, dann wandert der für mich unsichtbar ein einen @tmp des Volumes.
Das kann ich nur auf der Konsole so nachgucken. Und nein, einen Papierkorb nutze ich hier nicht.
.

Das ist mir neu und hatte ich auch noch nie bei einer regulären Datenlöschung über cifs/smb oder nfs. Auch auf der commandline nicht.

Noch eine Frage nebenbei: Gibt es bereits eine Anleitung wie btrfs volumes verkleinert werden können? Ich hatte den Anwendungsfall jetzt bereits zweimal und hatte hier nichts gefunden. Uns würde ich dazu mal was posten

 

[AndiHeitzer]

Ich kenne keine Möglichkeit, ein Volumen zu verkleinern.