[SOLVED] Speicherplatz im Hypervisor größer als in VM (ZFS RAID-Z2, keine SSDs), Trim-Problem (Discard-Option lässt sich unter cryptLUKS-Disk nicht aktvieren)

r4dh4l · Nov 15, 2020

Hallo,

ich habe ein RAIDZ-2 mit 4x3TB im Einsatz. Vor einer Weile lief mir das RAID voll (passierte mir früher immer, wenn ich Snapshots zu lange bestehen ließ, aber darauf achte ich seitdem immer). Durch Löschen einer ungenutzten VM bekam ich das System wieder zum Laufen, jetzt meldet der Hypervisor aber, dass ich nur noch ca. 6GB freien Speicher habe:

Code:

# zfs list -ospace
NAME                      AVAIL   USED  USEDSNAP  USEDDS  USEDREFRESERV  USEDCHILD
rpool                     7.45G  5.10T        0B    140K             0B      5.10T
rpool/ROOT                7.45G  7.10G        0B    140K             0B      7.10G
rpool/ROOT/pve-1          7.45G  7.10G        0B   7.10G             0B         0B
rpool/data                7.45G  5.08T        0B    140K             0B      5.08T
rpool/data/vm-101-disk-1  7.45G  17.8G        0B   17.8G             0B         0B
rpool/data/vm-101-disk-2  7.45G  4.93T        0B   4.93T             0B         0B
rpool/data/vm-103-disk-1  7.45G  8.03G        0B   8.03G             0B         0B
rpool/data/vm-104-disk-1  7.45G  8.94G        0B   8.94G             0B         0B
rpool/data/vm-104-disk-2  7.45G  73.8G        0B   73.8G             0B         0B
rpool/data/vm-105-disk-1  7.45G  5.76G        0B   5.76G             0B         0B
rpool/data/vm-107-disk-0  7.45G  8.15G        0B   8.15G             0B         0B
rpool/data/vm-108-disk-0  7.45G  8.72G        0B   8.72G             0B         0B
rpool/data/vm-109-disk-0  7.45G  8.21G        0B   8.21G             0B         0B
rpool/data/vm-110-disk-1  7.45G  6.26G        0B   6.26G             0B         0B
rpool/data/vm-111-disk-0  9.49G  8.25G        0B   6.22G          2.04G         0B
rpool/swap                7.45G  9.21G        0B   9.21G             0B         0B

Der Platzfresser scheint "rpool/data/vm-101-disk-2" mit 4,93TB zu sein.

Schaue ich aber auf die VM, in der diese Disk als Datenpartition dient, wird mir dort gesagt:

Code:

$ df -h /mnt/disk2/
Filesystem Size Used Avail Use% Mounted on
/mnt/disk2/  3.5T  2.8T  529G  85% /mnt/disk2/

1. Ist es so korrekt, dass die VM-seitigen 3,5TB auf Seiten des Hypervisors 4,93TB ergeben?

2. Ich habe auf der VM mit der entsprechenden Disk sogleich versucht, Speicher freizugeben (Seafile im Einsatz) und auch ca. 100GB freigeschaufelt. Davon will aber der Hypervisor nichts wissen. Woran kann das liegen?

Edit: Direkt zur Lösung

H4R0 · Nov 15, 2020

Block size von 64kb statt 8kb nehmen.

https://forum.proxmox.com/threads/virtual-disks-stealing-more-space-than-allocated-help.78349

r4dh4l · Nov 15, 2020

H4R0 said:
Block size von 64kb statt 8kb nehmen.

https://forum.proxmox.com/threads/virtual-disks-stealing-more-space-than-allocated-help.78349

Danke, aber:

1. Gibt es auch eine Weg, ohne die virtuelle Disk neu erstellen zu müssen?
2. Unklar ist mir weiterhin: Warum gibt ZFS keinen Speicher mehr frei, wenn man auf der betreffenden VM Daten löscht?
3. Soweit ich in https://pve.proxmox.com/pve-docs/pve-admin-guide.html#chapter_zfs verstanden habe scheint

Code:

# zfs get volsize,refreservation,used rpool/data/vm-101-disk-2
NAME                      PROPERTY        VALUE      SOURCE
rpool/data/vm-101-disk-2  volsize         3.50T      local
rpool/data/vm-101-disk-2  refreservation  none       default
rpool/data/vm-101-disk-2  used            4.93T      -

korrekt zu sein. Aber warum belegen denn die Daten einer VM bzw. eines ZVOLs nochmal Paritätsdaten, wenn mir von 4x3TB eh nur noch knapp 6TB übrig bleiben?

H4R0 · Nov 15, 2020

r4dh4l said:
Danke, aber:

1. Gibt es auch eine Weg, ohne die virtuelle Disk neu erstellen zu müssen?

Ja du kannst per zfs send receive das volume neu anlegen, voraussetzung du hast genug platz frei für eine kopie.

r4dh4l said:
2. Unklar ist mir weiterhin: Warum gibt ZFS keinen Speicher mehr frei, wenn man auf der betreffenden VM Daten löscht?

Hast du trim in der vm eingerichtet ? Ohne trim werden gelöschte dateien nicht an den hypervisor weitergegeben..

r4dh4l said:
3. Soweit ich in https://pve.proxmox.com/pve-docs/pve-admin-guide.html#chapter_zfs verstanden habe scheint

Code:

# zfs get volsize,refreservation,used rpool/data/vm-101-disk-2 NAME PROPERTY VALUE SOURCE rpool/data/vm-101-disk-2 volsize 3.50T local rpool/data/vm-101-disk-2 refreservation none default rpool/data/vm-101-disk-2 used 4.93T -

korrekt zu sein. Aber warum belegen denn die Daten einer VM bzw. eines ZVOLs nochmal Paritätsdaten, wenn mir von 4x3TB eh nur noch knapp 6TB übrig bleiben?

Der overhead ensteht durchs padding bei 4 festplatten nicht wegen der parity. Die parität ist schon enthalten im freien speicher.

r4dh4l · Nov 15, 2020

H4R0 said:
Ja du kannst per zfs send receive das volume neu anlegen, voraussetzung du hast genug platz frei für eine kopie.

Danke für den Tipp. Mit freiem Speicher sieht es ja gerade richtig übel aus. Kann "zfs send reseive" das Volume auch auf einem ext. Speicher neu erstellen, sodass ich nach dem Neuanlegen das alte löschen kann und schließlich das neue vom ext. Speicher zum "local-zfs" schieben kann?

H4R0 said:
Hast du trim in der vm eingerichtet ? Ohne trim werden gelöschte dateien nicht an den hypervisor weitergegeben..

Danke - "trim" war das entscheidende Stichwort! Ich konnte mich erinnern, dass ich vor Monaten schonmal genau dieses Problem hatte: https://forum.proxmox.com/threads/vm-speicherbedarf-laut-zfs-anders-als-laut-vm.63672/ - alleridngs konnte mir damals nichtmal der offizielle Support helfen.

H4R0 said:
Der overhead ensteht durchs padding bei 4 festplatten nicht wegen der parity. Die parität ist schon enthalten im freien speicher.

Danke, aber ginge es nochmal etwas mehr auf "Sendung mit der Maus"-Niveau? Das, was ich zu "zfs raid padding" finde erklärt nicht wirklich den Unterschiedz zwischen "parity" und "padding".

Dunuin · Nov 15, 2020

r4dh4l said:
Danke für den Tipp. Mit freiem Speicher sieht es ja gerade richtig übel aus. Kann "zfs send reseive" das Volume auch auf einem ext. Speicher neu erstellen, sodass ich nach dem Neuanlegen das alte löschen kann und schließlich das neue vom ext. Speicher zum "local-zfs" schieben kann?

Danke - "trim" war das entscheidende Stichwort! Ich konnte mich erinnern, dass ich vor Monaten schonmal genau dieses Problem hatte: https://forum.proxmox.com/threads/vm-speicherbedarf-laut-zfs-anders-als-laut-vm.63672/ - alleridngs konnte mir damals nichtmal der offizielle Support helfen.

Danke, aber ginge es nochmal etwas mehr auf "Sendung mit der Maus"-Niveau? Das, was ich zu "zfs raid padding" finde erklärt nicht wirklich den Unterschiedz zwischen "parity" und "padding".

Parity sind die Extra-Daten die du haben willst, damit nichts verloren geht, wenn dir eine HDD ausfällt. Padding ist der Overhead den du hast, weil die Daten aus der VM ja irgendwie auf 4 HDDs aufgeteilt werden müssen und weil die Blockgrößen zwischen LBA von der HDD, Volblocksize und ashift von ZFS sowie die Blockgröße des Dateisystems innerhalb der VM sich ja meistens unterscheiden. Mal ein vereinfachtes Beispiel zum groben Verständnis:
Hast du den Pool mit ashift 12 angelegt ist das Kleinste, was die HDDs speichern können, 4kb. Wenn du die Volblocksize beim Erstellen der virtuellen Festplatten nicht vom Standardwert von 8kb abgeändert hast, dann werden Daten von ZFS in 8kb Blocken bearbeitet. Dieser 8kb Block wird dann auf deine 4 HDDs aufgeteilt also soll jede HDD 2kb schreiben. Das kleinste was die schreiben können ist 4kb, also schreiben die 4x 4kb = 16kb. So werden deine 8kb zu 16kb und alle Daten nehmen also den doppelten Platz weg. Das kannst du umgehen, indem du eine größere Volblocksize wählst.
Guck mal die Tabelle hier, da gibt es Beispiele bei welcher Konfiguration sich welche Volblocksize lohnt. Nach der wäre 64k wohl auch das Beste für 4 HDDs im raidz2.
Ist leider ziemlich schwer auszurechnen, da neben den Paritätsdaten auch noch Metadaten zusätzlich anfallen. Und wenn Kompression genutzt wird, dann macht es alles wieder kleiner, je nach Komprimierbarkeit der Datei. Kann man also nur grob schätzen und etwas Padding-Overhead wird man deshalb immer haben. Das gleiche Problem hast du auch, wenn deine HDDs Daten schreiben sollen die größer als die 4kb sind, die mit ashift angegeben wurden. Sind das 5kb pro HDD, dann müssen halt 8kb geschrieben werden und du verlierst wieder eine Menge Platz. Je größer deine Volblocksize ist, desto weniger Kapazität verschwendest du durchs Padding, da ein Aufrunden auf das nächst größere Vielfache von 4kb dann im Verhältnis weniger ins Gewicht fällt. Dafür verschwendest du dann aber viel Platz, wenn du sehr kleine Schreiboperationen hast, wie es bei Datenbanken der Fall ist. Die wollen gerne mal in 8kb oder 16kb Blöcken schreiben und wenn die Volblocksize z.B. 128kb ist, dann nimmt alles mindestens 128kb ein, auch wenn nur 8kb geschrieben werden sollen.

So habe ich das jetzt jedenfalls verstanden.

Im übrigen solltest du den Pool nicht mehr als 80% füllen. Spätestens bei 90% bekommt ZFS sonst Probleme, da es ja ein Copy-On-Wirte-Dateisystem ist und daher immer genug freien Speicher benötigt um ordentlich und schnell arbeiten zu können.

Die Volblocksize lässt sich leider nur zum Zeitpunkt der Erstellung der virtuellen Festplatte setzen, also musst du die leider löschen. Hab ich auch hinter mir, weil ich das mit raidz und der volblocksize nicht wusste. Das sollte wirklich deutlicher im Wiki stehen, dass man da nicht so leicht als Anfänger auf diese fiese Falle reinfällt. Ich hatte mein Vorgehen mal hier für eine Debian-VM dokumentiert.

H4R0 · Nov 15, 2020

r4dh4l said:
Danke für den Tipp. Mit freiem Speicher sieht es ja gerade richtig übel aus. Kann "zfs send reseive" das Volume auch auf einem ext. Speicher neu erstellen, sodass ich nach dem Neuanlegen das alte löschen kann und schließlich das neue vom ext. Speicher zum "local-zfs" schieben kann?

Klar kannst auf eine extra festplatte kopieren, musst dann halt wieder zurück kopieren. Wäre es auf der selben hätte einmal kopieren und umbennenen gereicht. Du kannst auch über ssh auf ein anderen server kopieren. WIchtig ist das du beim receive dann die block size von 64k angibst. Wirst das halt für alle volumes machen müssen da es nicht per pool geht.

r4dh4l said:
Danke - "trim" war das entscheidende Stichwort! Ich konnte mich erinnern, dass ich vor Monaten schonmal genau dieses Problem hatte: https://forum.proxmox.com/threads/vm-speicherbedarf-laut-zfs-anders-als-laut-vm.63672/ - alleridngs konnte mir damals nichtmal der offizielle Support helfen.

Nicht in die crypttab sondern in fstab, nach den mount options "discard" hinzufügen und neustarten. Wenn "lsblk --discard" nicht 0 ist bei Disc-Gran ist trim aktiviert. Anschließend einmal "fstrim -a" laufen lassen und der speicher ist beim hypervisor frei. Beachte das discard bei luks die sicherheit beeinträchtigt.

r4dh4l said:
Danke, aber ginge es nochmal etwas mehr auf "Sendung mit der Maus"-Niveau? Das, was ich zu "zfs raid padding" finde erklärt nicht wirklich den Unterschiedz zwischen "parity" und "padding".

Siehe antwort von @Dunuin.

r4dh4l · Dec 7, 2020

Dunuin said:
Mal ein vereinfachtes Beispiel zum groben Verständnis:
Hast du den Pool mit ashift 12 angelegt ist das Kleinste, was die HDDs speichern können, 4kb. Wenn du die Volblocksize beim Erstellen der virtuellen Festplatten nicht vom Standardwert von 8kb abgeändert hast, dann werden Daten von ZFS in 8kb Blocken bearbeitet. Dieser 8kb Block wird dann auf deine 4 HDDs aufgeteilt also soll jede HDD 2kb schreiben. Das kleinste was die schreiben können ist 4kb, also schreiben die 4x 4kb = 16kb. So werden deine 8kb zu 16kb und alle Daten nehmen also den doppelten Platz weg. Das kannst du umgehen, indem du eine größere Volblocksize wählst.
Guck mal die Tabelle hier, da gibt es Beispiele bei welcher Konfiguration sich welche Volblocksize lohnt. Nach der wäre 64k wohl auch das Beste für 4 HDDs im raidz2.

Danke, durch das Beispiel habe ich das Problem besser verstanden. Verstehe ich die Tabelle korrekt, dass es in meinem Fall mit 4 Disks dann egal ist, ob ich eine 64er, 128er oder 256er VolBlockSize nehme? (alles mit 29% der niedrigste Wert)?

Dunuin · Dec 7, 2020

r4dh4l said:
Danke, durch das Beispiel habe ich das Problem besser verstanden. Verstehe ich die Tabelle korrekt, dass es in meinem Fall mit 4 Disks dann egal ist, ob ich eine 64er, 128er oder 256er VolBlockSize nehme? (alles mit 29% der niedrigste Wert)?

Ja, wobei ich dann zu 64K tendieren würde. Dann hast du immer noch die niedrigsten Wert von 29% aber kleine Dateien mit wenigen KB größe nehmen dann nur 64KB und nicht 128 oder 256KB weg.

r4dh4l · Dec 7, 2020

H4R0 said:
Nicht in die crypttab sondern in fstab, nach den mount options "discard" hinzufügen und neustarten.

Danke für die Klarstellung, ist sowohl in crypttab...

Code:

STORAGE /dev/sdb1 none luks,noauto,discard

...als auch in fstab gesetzt:

Code:

/dev/mapper/STORAGE /mnt/STORAGE ext4 defaults,users,noauto,exec,discard 0 0

H4R0 said:
Wenn "lsblk --discard" nicht 0 ist bei Disc-Gran ist trim aktiviert. Anschließend einmal "fstrim -a" laufen lassen und der speicher ist beim hypervisor frei.

Hm, leider nicht:

Code:

root@vm# lsblk --discard
NAME                           DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                                   0        4K       1G         0
├─sda1                                0        4K       1G         0
├─sda2                             1024        4K       1G         0
└─sda5                                0        4K       1G         0
  ├─vm--tmplt--deb9--vg-root          0        4K       1G         0
  └─vm--tmplt--deb9--vg-swap_1        0        4K       1G         0
sdb                                   0        4K       1G         0
└─STORAGE                             0        4K       1G         0
root@vm:~# fstrim -a
root@vm:~# df -h
Filesystem                            Size  Used Avail Use% Mounted on
udev                                  991M     0  991M   0% /dev
tmpfs                                 201M   21M  180M  11% /run
/dev/mapper/vm--tmplt--deb9--vg-root   15G  7.0G  7.4G  49% /
tmpfs                                1003M     0 1003M   0% /dev/shm
tmpfs                                 5.0M     0  5.0M   0% /run/lock
tmpfs                                1003M     0 1003M   0% /sys/fs/cgroup
/dev/sda1                             236M   63M  161M  29% /boot
tmpfs                                 201M     0  201M   0% /run/user/1004
/dev/mapper/STORAGE                   3.5T  2.7T  601G  83% /mnt/STORAGE
root@vm:~#

root@proxmox# df -h
Filesystem        Size  Used Avail Use% Mounted on
udev              7.6G     0  7.6G   0% /dev
tmpfs             1.6G   29M  1.5G   2% /run
rpool/ROOT/pve-1   16G  7.2G  8.1G  47% /
tmpfs             7.6G   25M  7.6G   1% /dev/shm
tmpfs             5.0M     0  5.0M   0% /run/lock
tmpfs             7.6G     0  7.6G   0% /sys/fs/cgroup
rpool             8.1G  128K  8.1G   1% /rpool
rpool/ROOT        8.1G  128K  8.1G   1% /rpool/ROOT
rpool/data        8.1G  128K  8.1G   1% /rpool/data
/dev/fuse          30M   48K   30M   1% /etc/pve
tmpfs             1.6G     0  1.6G   0% /run/user/1001
root@proxmox:~# zfs list
NAME                       USED  AVAIL  REFER  MOUNTPOINT
rpool                     5.10T  8.01G   140K  /rpool
rpool/ROOT                7.10G  8.01G   140K  /rpool/ROOT
rpool/ROOT/pve-1          7.10G  8.01G  7.10G  /
rpool/data                5.08T  8.01G   140K  /rpool/data
rpool/data/vm-101-disk-1  17.7G  8.01G  17.7G  -
rpool/data/vm-101-disk-2  4.94T  8.01G  4.94T  (das ist die STORAGE disk)
rpool/data/vm-103-disk-1  8.03G  8.01G  8.03G  -
rpool/data/vm-104-disk-1  8.80G  8.01G  8.80G  -
rpool/data/vm-104-disk-2  74.8G  8.01G  74.8G  -
rpool/data/vm-105-disk-1  5.75G  8.01G  5.75G  -
rpool/data/vm-107-disk-0  8.15G  8.01G  8.15G  -
rpool/data/vm-108-disk-0  8.33G  8.01G  8.33G  -
rpool/data/vm-109-disk-0  8.21G  8.01G  8.21G  -
rpool/data/vm-110-disk-1  6.26G  8.01G  6.26G  -
rpool/swap                9.24G  8.01G  9.24G  -
root@proxmox:~#

Hast Du noch eine Idee, was ich falsch gemacht haben könnte?

H4R0 · Dec 7, 2020

r4dh4l said:

Danke für die Klarstellung, ist sowohl in crypttab...

Code:

STORAGE /dev/sdb1 none luks,noauto,discard

...als auch in fstab gesetzt:

Code:

/dev/mapper/STORAGE /mnt/STORAGE ext4 defaults,users,noauto,exec,discard 0 0

Hm, leider nicht:

Code:

root@vm# lsblk --discard
NAME                           DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
sda                                   0        4K       1G         0
├─sda1                                0        4K       1G         0
├─sda2                             1024        4K       1G         0
└─sda5                                0        4K       1G         0
  ├─vm--tmplt--deb9--vg-root          0        4K       1G         0
  └─vm--tmplt--deb9--vg-swap_1        0        4K       1G         0
sdb                                   0        4K       1G         0
└─STORAGE                             0        4K       1G         0
root@vm:~# fstrim -a
root@vm:~# df -h
Filesystem                            Size  Used Avail Use% Mounted on
udev                                  991M     0  991M   0% /dev
tmpfs                                 201M   21M  180M  11% /run
/dev/mapper/vm--tmplt--deb9--vg-root   15G  7.0G  7.4G  49% /
tmpfs                                1003M     0 1003M   0% /dev/shm
tmpfs                                 5.0M     0  5.0M   0% /run/lock
tmpfs                                1003M     0 1003M   0% /sys/fs/cgroup
/dev/sda1                             236M   63M  161M  29% /boot
tmpfs                                 201M     0  201M   0% /run/user/1004
/dev/mapper/STORAGE                   3.5T  2.7T  601G  83% /mnt/STORAGE
root@vm:~#

root@proxmox# df -h
Filesystem        Size  Used Avail Use% Mounted on
udev              7.6G     0  7.6G   0% /dev
tmpfs             1.6G   29M  1.5G   2% /run
rpool/ROOT/pve-1   16G  7.2G  8.1G  47% /
tmpfs             7.6G   25M  7.6G   1% /dev/shm
tmpfs             5.0M     0  5.0M   0% /run/lock
tmpfs             7.6G     0  7.6G   0% /sys/fs/cgroup
rpool             8.1G  128K  8.1G   1% /rpool
rpool/ROOT        8.1G  128K  8.1G   1% /rpool/ROOT
rpool/data        8.1G  128K  8.1G   1% /rpool/data
/dev/fuse          30M   48K   30M   1% /etc/pve
tmpfs             1.6G     0  1.6G   0% /run/user/1001
root@proxmox:~# zfs list
NAME                       USED  AVAIL  REFER  MOUNTPOINT
rpool                     5.10T  8.01G   140K  /rpool
rpool/ROOT                7.10G  8.01G   140K  /rpool/ROOT
rpool/ROOT/pve-1          7.10G  8.01G  7.10G  /
rpool/data                5.08T  8.01G   140K  /rpool/data
rpool/data/vm-101-disk-1  17.7G  8.01G  17.7G  -
rpool/data/vm-101-disk-2  4.94T  8.01G  4.94T  (das ist die STORAGE disk)
rpool/data/vm-103-disk-1  8.03G  8.01G  8.03G  -
rpool/data/vm-104-disk-1  8.80G  8.01G  8.80G  -
rpool/data/vm-104-disk-2  74.8G  8.01G  74.8G  -
rpool/data/vm-105-disk-1  5.75G  8.01G  5.75G  -
rpool/data/vm-107-disk-0  8.15G  8.01G  8.15G  -
rpool/data/vm-108-disk-0  8.33G  8.01G  8.33G  -
rpool/data/vm-109-disk-0  8.21G  8.01G  8.21G  -
rpool/data/vm-110-disk-1  6.26G  8.01G  6.26G  -
rpool/swap                9.24G  8.01G  9.24G  -
root@proxmox:~#

Hast Du noch eine Idee, was ich falsch gemacht haben könnte?

Disc-Gran ist 4K, trim ist also aktiviert in der VM.

Poste mal ein Screenshot der VM Hardware in der Proxmox GUI

Und die Ausgabe von "zfs list -t snapshot | grep 101-disk-2" vom Host.

r4dh4l · Dec 11, 2020

H4R0 said:
Disc-Gran ist 4K, trim ist also aktiviert in der VM.

Poste mal ein Screenshot der VM Hardware in der Proxmox GUI

Danke für Deine Hilfe:

H4R0 said:
Und die Ausgabe von "zfs list -t snapshot | grep 101-disk-2" vom Host.

Code:

# zfs list -t snapshot | grep 101-disk-2
no datasets available
# zfs list -t snapshot
no datasets available

r4dh4l · Dec 13, 2020

Noch ein Nachtrag: Mir fiel auf, dass auf den System-Disks meiner VMs nirgends "Discard" aktiviert war. Eine Aktvierung und anschließend manuelles "sudo fstrim -v /" auf allen VMs legte zumindest ca. 60GB frei:

Code:

root@proxmox:~# df -h
Filesystem        Size  Used Avail Use% Mounted on
...
rpool/ROOT/pve-1   15G  7.2G  7.9G  48% /    <- VOR fstrim auf den VMs!
...
root@proxmox:~# df -h
Filesystem        Size  Used Avail Use% Mounted on
...
rpool/ROOT/pve-1   69G  7.2G   62G  11% /    <- NACH fstrim auf den VMs!
...
root@proxmox:~#

Was nach wie vor auf der VM im letzten Screenshot nicht funktioniert:

Code:

root@vm-seafile:~# fstrim -v /mnt/STORAGE
fstrim: /mnt/STORAGE: the discard operation is not supported

Warum sagt Proxmox, dass die Discard-Option gesetzt ist ("STORAGE" = "vm-101-disk2"), aber die VM selbst nicht?

H4R0 · Dec 13, 2020

r4dh4l said:
Danke für Deine Hilfe:

View attachment 21947

Code:

# zfs list -t snapshot | grep 101-disk-2 no datasets available # zfs list -t snapshot no datasets available

Hmm stimmt alles, virtio scsi ist richtig und discard is gesetzt.

Eigentlich müsste trim ohne weiteres laufen.

Das einzige was du noch machen könntest ist prüfen ob luks auch wirklich discard aktiviert hat

Die Ausgabe von "dmsetup table" muss "allow_discards" am ende stehen haben.

Aber da lsblk es bereits anzeigt sollte es eigentlich der Fall sein.

r4dh4l · Dec 13, 2020

H4R0 said:
Die Ausgabe von "dmsetup table" muss "allow_discards" am ende stehen haben.

Aber da lsblk es bereits anzeigt sollte es eigentlich der Fall sein.

Ne, steht nicht:

Code:

root@vm-seafile:~# dmsetup table

vm--tmplt--deb9--vg-root: 0 15220736 linear 8:5 2048

vm--tmplt--deb9--vg-root: 15220736 16777216 linear 8:5 16271360

vm--tmplt--deb9--vg-swap_1: 0 1048576 linear 8:5 15222784

STORAGE: 0 7516188672 crypt aes-xts-plain64 0000000000000000000000000000000000000000000000000000000000000000 0 8:16 4096
root@vm-seafile:~#

An welcher Stellschraube muss ich jetzt nochmal schauen?

H4R0 · Dec 13, 2020

r4dh4l said:

Ne, steht nicht:

Code:

root@vm-seafile:~# dmsetup table

vm--tmplt--deb9--vg-root: 0 15220736 linear 8:5 2048

vm--tmplt--deb9--vg-root: 15220736 16777216 linear 8:5 16271360

vm--tmplt--deb9--vg-swap_1: 0 1048576 linear 8:5 15222784

STORAGE: 0 7516188672 crypt aes-xts-plain64 0000000000000000000000000000000000000000000000000000000000000000 0 8:16 4096
root@vm-seafile:~#

An welcher Stellschraube muss ich jetzt nochmal schauen?

Hattest du nach den crypttab/fstab änderungen initram und grub geupdated ?

update-initramfs -u
update-grub
reboot

Wenn das immer noch nicht geht kannst du folgendes versuchen:

cryptsetup -v --allow-discards --persistent refresh /dev/sdb1

Das setzt die discard option in den luks header unabhängig von mount optionen.

Anschließend rebooten und nochmal bei dmsetup table schauen

r4dh4l · Dec 13, 2020

H4R0 said:
Hattest du nach den crypttab/fstab änderungen initram und grub geupdated ?

Ich denke schon, habe aber nochmal...

H4R0 said:
update-initramfs -u
update-grub
reboot

...ausgeführt:

Code:

root@vm-seafile:~# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.9.0-14-amd64
root@vm-seafile:~# update-grub
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-4.9.0-14-amd64
Found initrd image: /boot/initrd.img-4.9.0-14-amd64
Found linux image: /boot/vmlinuz-4.9.0-13-amd64
Found initrd image: /boot/initrd.img-4.9.0-13-amd64
done
root@vm-seafile:~# shutdown -h now
Connection to vm-seafile closed by remote host.
Connection to vm-seafile closed.
r4dh4l@notebook:~$

Hat leider nichts gebracht:

Code:

root@vm-seafile:~# dmsetup table
vm--tmplt--deb9--vg-root: 0 15220736 linear 8:5 2048
vm--tmplt--deb9--vg-root: 15220736 16777216 linear 8:5 16271360
vm--tmplt--deb9--vg-swap_1: 0 1048576 linear 8:5 15222784
STORAGE: 0 7516188672 crypt aes-xts-plain64 0000000000000000000000000000000000000000000000000000000000000000 0 8:16 4096

H4R0 said:
Wenn das immer noch nicht geht kannst du folgendes versuchen:

cryptsetup -v --allow-discards --persistent refresh /dev/sdb1

Code:

root@vm-seafile:~# cryptsetup -v --allow-discards --persistent refresh /dev/sdb1
Usage: cryptsetup [-?vyrq] [-?|--help] [--usage] [--version] [-v|--verbose] [--debug] [-c|--cipher=STRING] [-h|--hash=STRING] [-y|--verify-passphrase]
        [-d|--key-file=STRING] [--master-key-file=STRING] [--dump-master-key] [-s|--key-size=BITS] [-l|--keyfile-size=bytes] [--keyfile-offset=bytes]
        [--new-keyfile-size=bytes] [--new-keyfile-offset=bytes] [-S|--key-slot=INT] [-b|--size=SECTORS] [-o|--offset=SECTORS] [-p|--skip=SECTORS]
        [-r|--readonly] [-i|--iter-time=msecs] [-q|--batch-mode] [-t|--timeout=secs] [-T|--tries=INT] [--align-payload=SECTORS]
        [--header-backup-file=STRING] [--use-random] [--use-urandom] [--shared] [--uuid=STRING] [--allow-discards] [--header=STRING]
        [--test-passphrase] [--tcrypt-hidden] [--tcrypt-system] [--tcrypt-backup] [--veracrypt] [-M|--type=STRING] [--force-password]
        [--perf-same_cpu_crypt] [--perf-submit_from_crypt_cpus] [OPTION...] <action> <action-specific>
--persistent: unknown option
root@vm-seafile:~# cryptsetup luksDump /dev/sdb1 | grep Flags
Device /dev/sdb1 doesn't exist or access denied.
root@vm-seafile:~# lsblk
NAME                           MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                              8:0    0   16G  0 disk
├─sda1                           8:1    0  243M  0 part  /boot
├─sda2                           8:2    0    1K  0 part
└─sda5                           8:5    0 15.8G  0 part
  ├─vm--tmplt--deb9--vg-root   254:0    0 15.3G  0 lvm   /
  └─vm--tmplt--deb9--vg-swap_1 254:1    0  512M  0 lvm   [SWAP]
sdb                              8:16   0  3.5T  0 disk
└─STORAGE                    254:2    0  3.5T  0 crypt /mnt/STORAGE
root@vm-seafile:~# cryptsetup luksDump /dev/sdb | grep Flags
root@vm-seafile:~# cryptsetup -v --allow-discards --persistent refresh /dev/sdb
Usage: cryptsetup [-?vyrq] [-?|--help] [--usage] [--version] [-v|--verbose] [--debug] [-c|--cipher=STRING] [-h|--hash=STRING] [-y|--verify-passphrase]
        [-d|--key-file=STRING] [--master-key-file=STRING] [--dump-master-key] [-s|--key-size=BITS] [-l|--keyfile-size=bytes] [--keyfile-offset=bytes]
        [--new-keyfile-size=bytes] [--new-keyfile-offset=bytes] [-S|--key-slot=INT] [-b|--size=SECTORS] [-o|--offset=SECTORS] [-p|--skip=SECTORS]
        [-r|--readonly] [-i|--iter-time=msecs] [-q|--batch-mode] [-t|--timeout=secs] [-T|--tries=INT] [--align-payload=SECTORS]
        [--header-backup-file=STRING] [--use-random] [--use-urandom] [--shared] [--uuid=STRING] [--allow-discards] [--header=STRING]
        [--test-passphrase] [--tcrypt-hidden] [--tcrypt-system] [--tcrypt-backup] [--veracrypt] [-M|--type=STRING] [--force-password]
        [--perf-same_cpu_crypt] [--perf-submit_from_crypt_cpus] [OPTION...] <action> <action-specific>
--persistent: unknown option
root@vm-seafile:~#

H4R0 said:
Das setzt die discard option in den luks header unabhängig von mount optionen.

Kann es sein, dass ich hier eine zu alte Version von cryptsetup in Verwendung habe?

Code:

root@vm-seafile:~# cryptsetup --version
cryptsetup 1.7.3
root@vm-seafile:~# apt policy cryptsetup
cryptsetup:
  Installed: 2:1.7.3-4
  Candidate: 2:1.7.3-4
  Version table:
*** 2:1.7.3-4 500
        500 http://ftp.de.debian.org/debian stretch/main amd64 Packages
        100 /var/lib/dpkg/status
root@vm-seafile:~#

H4R0 · Dec 13, 2020

r4dh4l said:

Ich denke schon, habe aber nochmal...

...ausgeführt:

Code:

root@vm-seafile:~# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.9.0-14-amd64
root@vm-seafile:~# update-grub
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-4.9.0-14-amd64
Found initrd image: /boot/initrd.img-4.9.0-14-amd64
Found linux image: /boot/vmlinuz-4.9.0-13-amd64
Found initrd image: /boot/initrd.img-4.9.0-13-amd64
done
root@vm-seafile:~# shutdown -h now
Connection to vm-seafile closed by remote host.
Connection to vm-seafile closed.
r4dh4l@notebook:~$

Hat leider nichts gebracht:

Code:

root@vm-seafile:~# dmsetup table
vm--tmplt--deb9--vg-root: 0 15220736 linear 8:5 2048
vm--tmplt--deb9--vg-root: 15220736 16777216 linear 8:5 16271360
vm--tmplt--deb9--vg-swap_1: 0 1048576 linear 8:5 15222784
STORAGE: 0 7516188672 crypt aes-xts-plain64 0000000000000000000000000000000000000000000000000000000000000000 0 8:16 4096

Code:

root@vm-seafile:~# cryptsetup -v --allow-discards --persistent refresh /dev/sdb1
Usage: cryptsetup [-?vyrq] [-?|--help] [--usage] [--version] [-v|--verbose] [--debug] [-c|--cipher=STRING] [-h|--hash=STRING] [-y|--verify-passphrase]
        [-d|--key-file=STRING] [--master-key-file=STRING] [--dump-master-key] [-s|--key-size=BITS] [-l|--keyfile-size=bytes] [--keyfile-offset=bytes]
        [--new-keyfile-size=bytes] [--new-keyfile-offset=bytes] [-S|--key-slot=INT] [-b|--size=SECTORS] [-o|--offset=SECTORS] [-p|--skip=SECTORS]
        [-r|--readonly] [-i|--iter-time=msecs] [-q|--batch-mode] [-t|--timeout=secs] [-T|--tries=INT] [--align-payload=SECTORS]
        [--header-backup-file=STRING] [--use-random] [--use-urandom] [--shared] [--uuid=STRING] [--allow-discards] [--header=STRING]
        [--test-passphrase] [--tcrypt-hidden] [--tcrypt-system] [--tcrypt-backup] [--veracrypt] [-M|--type=STRING] [--force-password]
        [--perf-same_cpu_crypt] [--perf-submit_from_crypt_cpus] [OPTION...] <action> <action-specific>
--persistent: unknown option
root@vm-seafile:~# cryptsetup luksDump /dev/sdb1 | grep Flags
Device /dev/sdb1 doesn't exist or access denied.
root@vm-seafile:~# lsblk
NAME                           MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINT
sda                              8:0    0   16G  0 disk
├─sda1                           8:1    0  243M  0 part  /boot
├─sda2                           8:2    0    1K  0 part
└─sda5                           8:5    0 15.8G  0 part
  ├─vm--tmplt--deb9--vg-root   254:0    0 15.3G  0 lvm   /
  └─vm--tmplt--deb9--vg-swap_1 254:1    0  512M  0 lvm   [SWAP]
sdb                              8:16   0  3.5T  0 disk
└─STORAGE                    254:2    0  3.5T  0 crypt /mnt/STORAGE
root@vm-seafile:~# cryptsetup luksDump /dev/sdb | grep Flags
root@vm-seafile:~# cryptsetup -v --allow-discards --persistent refresh /dev/sdb
Usage: cryptsetup [-?vyrq] [-?|--help] [--usage] [--version] [-v|--verbose] [--debug] [-c|--cipher=STRING] [-h|--hash=STRING] [-y|--verify-passphrase]
        [-d|--key-file=STRING] [--master-key-file=STRING] [--dump-master-key] [-s|--key-size=BITS] [-l|--keyfile-size=bytes] [--keyfile-offset=bytes]
        [--new-keyfile-size=bytes] [--new-keyfile-offset=bytes] [-S|--key-slot=INT] [-b|--size=SECTORS] [-o|--offset=SECTORS] [-p|--skip=SECTORS]
        [-r|--readonly] [-i|--iter-time=msecs] [-q|--batch-mode] [-t|--timeout=secs] [-T|--tries=INT] [--align-payload=SECTORS]
        [--header-backup-file=STRING] [--use-random] [--use-urandom] [--shared] [--uuid=STRING] [--allow-discards] [--header=STRING]
        [--test-passphrase] [--tcrypt-hidden] [--tcrypt-system] [--tcrypt-backup] [--veracrypt] [-M|--type=STRING] [--force-password]
        [--perf-same_cpu_crypt] [--perf-submit_from_crypt_cpus] [OPTION...] <action> <action-specific>
--persistent: unknown option
root@vm-seafile:~#

Kann es sein, dass ich hier eine zu alte Version von cryptsetup in Verwendung habe?

Code:

root@vm-seafile:~# cryptsetup --version
cryptsetup 1.7.3
root@vm-seafile:~# apt policy cryptsetup
cryptsetup:
  Installed: 2:1.7.3-4
  Candidate: 2:1.7.3-4
  Version table:
*** 2:1.7.3-4 500
        500 http://ftp.de.debian.org/debian stretch/main amd64 Packages
        100 /var/lib/dpkg/status
root@vm-seafile:~#

Ja das geht erst mit luks 2.0 welches ab buster dabei ist.

Da stretch eol ist würde ich dir empfehlen zu updaten.

r4dh4l · Dec 14, 2020

H4R0 said:
Ja das geht erst mit luks 2.0 welches ab buster dabei ist.

Da stretch eol ist würde ich dir empfehlen zu updaten.

Was für eine Odyssee.

Aber ja, Du hast vollkommen Recht. Ich hatte noch keine Dist-Upgrades vorgenommen, weil ich kein Platz für Snapshots hatte. Die 60GB, die nun frei geworden sind, sind Glück im Unglück. Ich melde mich, wenn ich mit dem Dist-Upgrade durch bin. Danke!

r4dh4l · Dec 15, 2020

Nach einem PM-Wechsel mit @H4R0 hat sich die Lösung des Trim-Problems wie folgt ergeben:

Da ich die betroffenen verschlüsselte Disk manuell nach dem VM-Start entsperre, wurden die discard-Optionen in crypttab/fstab immer ignoriert, sofern man cryptsetup die entsprechende Option beim Entsperren nicht manuell mitgibt. Man muss dann also statt etwas wie

Code:

cryptsetup luksOpen /dev/sdX STORAGE && mount /dev/mapper/STORAGE

Folgenden BEfehl zum Entsperren nutzen:

Code:

cryptsetup luksOpen --allow-discards /dev/sdX STORAGE && mount /dev/mapper/STORAGE

Daraufhin wurde die discard-Option endlich übernommen:

Code:

# dmsetup table
vm--tmplt--deb9--vg-root: 0 15220736 linear 8:5 2048
vm--tmplt--deb9--vg-root: 15220736 16777216 linear 8:5 16271360
vm--tmplt--deb9--vg-swap_1: 0 1048576 linear 8:5 15222784
STORAGE: 0 7516188672 crypt aes-xts-plain64 0000000000000000000000000000000000000000000000000000000000000000 0 8:16 4096 1 allow_discards

Da ich die Partition nie "getrimt" hatte, dauerte dies mehrere Stunden und schaufelte beachtliche 760GB frei:

Code:

# fstrim -v /mnt/STORAGE
/mnt/BIGREDVHD: 763.2 GiB (819434524672 bytes) trimmed

Proxmox konnte sogleich wieder etwas "atmen":

Damit ist die Kernprobelmatik erstmal gelöst. Vielen Dank für die viele und geduldige Hilfe!

[SOLVED] Speicherplatz im Hypervisor größer als in VM (ZFS RAID-Z2, keine SSDs), Trim-Problem (Discard-Option lässt sich unter cryptLUKS-Disk nicht aktvieren)

Active Member

Well-Known Member

Active Member

Well-Known Member

Active Member

Distinguished Member

Well-Known Member

Active Member

Distinguished Member

Active Member

Well-Known Member

Active Member

Active Member

Well-Known Member

Active Member

Well-Known Member

Active Member

Well-Known Member

Active Member

Active Member