[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)

R

r4dh4l

Active Member
Proxmox Subscriber
Feb 5, 2018
88
7
28
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
 
Last edited:
H4R0 said:
Block size von 64kb statt 8kb nehmen.

https://forum.proxmox.com/threads/virtual-disks-stealing-more-space-than-allocated-help.78349
Click to expand...
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?
 
r4dh4l said:
Danke, aber:

1. Gibt es auch eine Weg, ohne die virtuelle Disk neu erstellen zu müssen?
Click to expand...
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?
Click to expand...
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?
Click to expand...
Der overhead ensteht durchs padding bei 4 festplatten nicht wegen der parity. Die parität ist schon enthalten im freien speicher.
 
H4R0 said:
Ja du kannst per zfs send receive das volume neu anlegen, voraussetzung du hast genug platz frei für eine kopie.
Click to expand...
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..
Click to expand...
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.
Click to expand...
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".
 
Last edited:
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".
Click to expand...
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.
 
Last edited:
  • Like
Reactions: r4dh4l
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?
Click to expand...
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.
Click to expand...
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".
Click to expand...
Siehe antwort von @Dunuin.
 
  • Like
Reactions: r4dh4l
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.
Click to expand...
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)?
 
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)?
Click to expand...
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.
 
  • Like
Reactions: r4dh4l
H4R0 said:
Nicht in die crypttab sondern in fstab, nach den mount options "discard" hinzufügen und neustarten.
Click to expand...
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.
Click to expand...
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?
 
Last edited:
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?
Click to expand...

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.
 
H4R0 said:
Disc-Gran ist 4K, trim ist also aktiviert in der VM.

Poste mal ein Screenshot der VM Hardware in der Proxmox GUI
Click to expand...

Danke für Deine Hilfe:

vm-hardware2020-12-10_01-56-40.png

H4R0 said:
Und die Ausgabe von "zfs list -t snapshot | grep 101-disk-2" vom Host.
Click to expand...
Code: 
# zfs list -t snapshot | grep 101-disk-2
no datasets available
# zfs list -t snapshot
no datasets available
 
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?
 
Last edited:
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
Click to expand...

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.
 
  • Like
Reactions: r4dh4l
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.
Click to expand...

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?
 
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?
Click to expand...

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
 
  • Like
Reactions: r4dh4l
H4R0 said:
Hattest du nach den crypttab/fstab änderungen initram und grub geupdated ?
Click to expand...
Ich denke schon, habe aber nochmal...
H4R0 said:
update-initramfs -u
update-grub
reboot
Click to expand...
...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
Click to expand...

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.
Click to expand...

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:~#
 
Last edited:
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:~#
Click to expand...

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

Da stretch eol ist würde ich dir empfehlen zu updaten.
 
  • Like
Reactions: r4dh4l
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.
Click to expand...
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!
 
Last edited:
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":

screenshot_2020-12-15_12-30-57.png

Damit ist die Kernprobelmatik erstmal gelöst. Vielen Dank für die viele und geduldige Hilfe! :)
 
Last edited:
You must log in or register to reply here.

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!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

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!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom