Timeout beim Löschen des entfernen Replikats bei Entfernung der Replikation

[carsten2]

Ich habe die Replikation von einer VM entfernt. Dabei muss auch das entfernte Replikat entfernt werden. Hier scheint aber ein zu kurzer Timeout konfiguriert zu sein, denn es gibt einen Timeout-Fehler. Ich würde das als Bug einschätzen, denn das Löschen eines ZFS-Vols kann durchaus schon mal ein bisschen dauern.

Log-Ausgabe:
2019-09-27 10:18:01 105-0: start replication job
2019-09-27 10:18:01 105-0: guest => VM 105, running => 10286
2019-09-27 10:18:01 105-0: volumes => vmdata1zfs:vm-105-disk-1
2019-09-27 10:18:01 105-0: start job removal - mode 'full'
2019-09-27 10:18:02 105-0: (remote_prepare_local_job) delete stale replication snapshot '__replicate_105-0_1569571907__' on vmdata1zfs:vm-105-disk-1
2019-09-27 10:18:02 105-0: (remote_prepare_local_job) 105-0: delete stale volume 'vmdata1zfs:vm-105-disk-1'
2019-09-27 10:18:10 105-0: (remote_prepare_local_job) command 'zfs destroy -r data1/vmdata1/vm-105-disk-1' failed: got timeout
2019-09-27 10:18:10 105-0: end replication job with error: command '/usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=hal9030' root@192.168.42.30 -- pvesr prepare-local-job 105-0 --scan vmdata1zfs --last_sync 1 --force' failed: exit code 4

 

[fiona]

Hallo,
danke für die Meldung. Ja, der Timeout ist derzeit mit 5 Sekunden etwas knapp bemessen.
Als Workaround könntest Du versuchen die Replikation des Volumes vorher manuell zu löschen.

 

[carsten2]

Wird der Timeout denn in Zukunft angepasst? Das sollte er? Ich habe auch Replikationsaufträge, die ab und zu mit einem Timeout beim "zfs snapshot" fehlschlagen. Die Timeouts der zfs-Befehle scheinen alle zu knapp bemessen zu sein. Es stellt sich sowieso die Frage, in wiefern da überhaupt ein Timeout hingehört, denn eigentlich müsste doch wohl so lange gewartet werden, bis der zfs-Befehl fertig wird. Ich kann mir keinen Fall vorstellen, wo ein zfs-Befehl einfach ewig hängenbleibt. Sollte das der Fall sein, wäre das wohl ein schwerer Fehler im zfs-System bzw. Dateisystem.

 

[fiona]

Leider ist es nicht ganz einfach das Timeout zu erhöhen, da auch andere Komponenten von unserem Stack die relevanten Methoden benutzen, die jedenfalls Timeouts brauchen. Hier ist die Diskussion dazu auf der Mailing-Liste. Ich werde mir nochmal anschauen, ob wir die Timeouts für pvesr im Speziellen erhöhen können.

 

[carsten2]

Ich lösche geade einen großes zfs-Dateiensystem eines Containers, was anscheinend größtenteils im Hintergrund ausgeführt wird. Schon da gab es in der Proxmox-Console einen Timeout und man konnte den "zfs destroy" Befehl noch danach in der Prozessliste für einige Zeit sehen. Dann verschwand er, er ab er der Pool hat weiterhin hohe IO-Last und die freigegeben GB bei "zfs list" wachsen erst langsam an.

Aktuell dauert "zfs create tank/testfs" ca. 1,10 Minuten und "zfs destroy tank/testfs" ca. 5 Minuten. D.h. JEDER Befehl zum Anlegen uznd Löschen von weiteren Filesystemen, Volumns oder VMs endet mit einem Timeout, was wirklich sehr negativ ist.

Ein weiteres Problem, von dem ich nicht weiß, ob es damit zusammenhängt ist, dass ich einen Container habe, der nur eine Root-Disk, subvol-103-disk-1, genannt hat, und bei dem das Hinzufügen eines weiteres Mountpoints ZWEI zfs datasets erzeugt, nämlich subvol-103-disk-0 und subvol-103-disk-2, wobei es hier auch einen Timeout gibt, aber nach dem Neustart alles in Ordnung zu sein scheint. Das Dateisystem subvol-103-disk-0 wird aber nachher nirgends verwendet. Warum wird dies von Proxmox erstellt?