Cannot destroy dataset xxx: dataset already exists

SimonR

Active Member
Jan 2, 2020
35
6
28
Hallo zusammen,

nach einem mißglückten Sync mit zfs-autobackup kann ich auf meinem Target-Server die ZFS-Datasets nicht löschen.

Das merkwürdigste daran ist, dass ich vorher alle Snapshots der Datasets gelöscht habe, aber trotzdem bei USEDCHILD Daten angezeigt werden, obwohl keine Children mehr existieren. Die Datasets sind encrypted unter rpool/crypt und entsperrt/mounted. Es gibt keine VM auf dem Proxmox-Server, der Proxmox-Server dient also nur als Backup-Target, daher ist es ausgeschlossen, dass sie evt. in Nutzung sind. Umbenennen konnte ich die Datasets, die es betrifft. Aber Löschen geht einfach nicht. Ich habe jetzt mal einen Scrub auf dem Pool gestartet, der dauert allerdings 2-3 Tage, und ich gehe auch nicht davon aus, dass Datenfehler vorliegen, denn eine Test-Einbindung der Datasets in einer VM zeigten dass sie lauffähig und nicht korrupt sind. Aber woher kommt die Angabe in USEDCHILD und wie werde ich das wieder los, damit ich sie löschen kann? Clones der Datasets existieren auch keine.

1669468773533.png

Hier markiert die USEDCHILD-Angaben, obwohl keine Snapshots mehr existieren.

1669469025975.png

Dass ich die gesamte Replikation der betreffenden Datasets neu starten muss, ist mir klar, als Full-Sync. Aber wie werde ich die alten Datasets los und bringe ZFS bei, dass es keine CHILD-Daten mehr gibt. Ich würde ungerne den ganzen Pool killen, weil dann alles neu synchronisiert werden muss.

Neu gestartet habe ich natürlich den Proxmox-Server auch schon ein paarmal, aber es bleibt dabei, ich kann die Datasets nicht löschen. Einen neuen Snapshot der Datasets kann ich auch erstellen, und diesen auch löschen, aber das Dataset nicht.

Wäre toll, wenn hier jemand einen Tipp hätte.
 
Last edited:
läuft vielleicht noch eine replication? ich habe zb diesen blog eintrag gefunden wo das der fall war und den gleichen fehler beim löschen produziert hat: https://oshogbo.vexillium.org/blog/69/
Das dachte ich auch erst, aber da läuft nichts mehr, den Server habe ich ja auch mehrmals neu gestartet.

ps aux | grep zfs

zeigt keine Prozesse. Es gibt im Dataset auch keine "verlorenen" Resume-Tokens.

Aufgetreten ist das wohl, weil ich das Dataset von einem anderen Server repliziert habe mit zfs-autobackup. Die Datasets sind auf Quell- und Zielserver jeweils mit unterschiedlichen Keys verschlüsselt und zfs-autobackup entschlüsselt es vorm Transfer on the fly und verschlüsselt es dann neu auf dem Zielserver. Vor einer Replikation hatte ich aber auf dem Zielserver vergessen, die Datasets ordentlich zu mounten und den Key einzugeben. Lustigerweise hat zfs-autobackup aber trotzdem den Transfer gestartet. Und während des Transfers habe ich dann "nachträglich" die Datasets gemountet mit Keyeingabe.... und ich glaube, dann passiert etwas, was ZFS überhaupt nicht mag oder interpretieren kann. Mit dem entsprechenden Ergebnis.

Wenn auf dem Dataset noch irgendwas laufen würde, könnte ich es ja auch nicht umbennen und so quasi den Pfad ändern. Ich habe es jetzt zwar so gelöst, dass ich im betreffenden grossen Dataset von 19 TB es einfach eingebunden habe in eine Linux VM und das darauf enthaltene Logical Volume komplett gekillt habe. Durch das Trimming wurde der Speicher auf dem Zielserver dann auch wieder frei. Bis auf die 1,irgendwas TB, die auch als CHILDDATA angezeigt werden. Aber es gibt kein Child, alle Snapshots sind gelöscht.

Irgendwie extrem merkwürdig.

Was macht bspw. zfs-send | receive, wenn es angewiesen wird, es neu zu verschlüsseln, auf ein verschlüsseltes Dataset trifft, das aber nicht entsperrt ist. Merkwürdig, denn übertragen hat es definitiv Daten in exakt dem Dataset.

Nur für die Zukunft, und ich wäre da um einen Tipp dankbar, geht das? Kann ZFS receive in ein unentsperrtes encrypted Dataset schreiben? Und dabei nichts kaputt machen?

Löschen kann ich die Datasets weiterhin nicht.
 
Last edited:
mhmm ich bin mir nicht wirklich sicher was zfs-autobackup genau macht, aber soweit ich es verstanden habe muss das dataset nicht entschlüsselt werden um es zu schreiben (da die daten ja nur verschlüsselt werden)

ich würde vielleicht direkt bei zfs ein issue aufmachen mit den genauen befehlen die dazu geführt haben + die fehlermeldungen, vielleicht weiß dort jemand mehr bescheid:

https://github.com/openzfs/zfs/issues
 
mhmm ich bin mir nicht wirklich sicher was zfs-autobackup genau macht, aber soweit ich es verstanden habe muss das dataset nicht entschlüsselt werden um es zu schreiben (da die daten ja nur verschlüsselt werden)

ich würde vielleicht direkt bei zfs ein issue aufmachen mit den genauen befehlen die dazu geführt haben + die fehlermeldungen, vielleicht weiß dort jemand mehr bescheid:

https://github.com/openzfs/zfs/issues
Das ist/war wohl echt noch ein Bug im ZFS, hier beschrieben. Gelangt der Bugfix auch in die Proxmox ZFS Version?
https://github.com/openzfs/zfs/pull/14119

Los wird man die Volumes oder Datasets wohl nicht mehr... konnte mir Gott sei Dank anders helfen, zwar nicht ganz sauber, aber ohne Pool Destroy.
https://github.com/openzfs/zfs/pull/14119#issuecomment-1331894521

Und solange das nicht im ZFS offiziell drin ist: Verschlüsselte Target Volumes und Datasets immer vor inkrementellen Receives entschlüsseln, sonst ist Essig. Insbesondere muss man aufpassen, wenn diese Send | Receive per Cron laufen und auf keinen Fall vergessen, mit dem Key zu mounten.
 
Last edited:
  • Like
Reactions: Dunuin
Gelangt der Bugfix auch in die Proxmox ZFS Version?
früher oder später schon, soweit ich sehen kann ist der fix im zfs 2.1.7 drin (aktuell ist momentan 2.1.6)

solche bugs mit encryption + send/receive sind ein grund warum wir encryption auf zfs noch nicht integriert haben...
 
früher oder später schon, soweit ich sehen kann ist der fix im zfs 2.1.7 drin (aktuell ist momentan 2.1.6)

solche bugs mit encryption + send/receive sind ein grund warum wir encryption auf zfs noch nicht integriert haben...

joa, kann aber momentan innerhalb Proxmox auch passieren, wenn man einen verschlüsselten ZFS-Pfad als pve storage nutzt und Replication aktiviert hat. Denn dort werden ja auch inkrementelle Snaps gesynct.
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!