VMware Image shrinken

[Koffein71]

Hallo Forum,

ich habe hier unter VMware Workstation eine FreeBSD VM mit ZFS.

Die Festplatten-Imagedatei ist inzwischen auf 57 GB angewachsen, obwohl im Dateisystem
nur 12 GB belegt sind. Es war nie annähernd soviel Platz in der VM verbraucht
worden. Evtl. wird dies durch das 'copy on write' von ZFS verursacht !?

Ich habe schon versucht, das Image zu shrinken. Aber ohne Erfolg.
Ich hatte einen 'scrub' durchgeführt. Aber die Imagedatei lies sich auch danach nicht shrinken.
Gibt es mit ZFS eine Möglichkeit zur Defragmentierung ? Oder gibt es hier noch andere Effekte
die ich nicht bedacht habe ?

Als Notlösung fällt mir nur ein, eine neue Platte einzubinden und die ganze
Installation zu übertragen.


Gruß
Koffein71

 

[TCM]

Na sicher entsteht das durch CoW. Wieviel hast du denn zugewiesen und warum, wenn das jetzt ein Problem ist?

 

[Koffein71]

Das Image kann bis 64 GB wachsen. Mehr als ausreichend.
Mein Problem ist: ich will die häufig genutzten VMs auf die SSD schieben.
Dazu muss ich halt ein bisschen Platz sparen, damit das passt.

 

[Azazyel]

Oder gibt es hier noch andere Effekte
die ich nicht bedacht habe?

VMware kann ein Image nur verkleinern, wenn Blöcke im Image entweder mit lauter Nullen gefüllt oder als gelöscht markiert wurden (via TRIM).

Wenn eine Datei via rm gelöscht wurde, ist ihr Inhalt (solange er nicht anderweitig überschrieben wurde) immer noch im Image physikalisch vorhanden. VMware hat ohne TRIM keine Möglichkeit der Unterscheidung, ob der jeweilige Block zu einem gelöschten oder einem noch genutzten Bereich gehört. Du kannst aber (solange Datenkompression deaktiviert ist) die nicht benutzen Blöcke weitestgehend mit Nullen überschreiben:
https://forums.freebsd.org/threads/49236/
Anschließend sollte auch das Verkleinern wieder klappen, wobei du ohne TRIM früher oder später wieder in obige Situation laufen wirst.

 

[TCM]

Wie sieht denn sysctl bei dir aus? Ist TRIM aktiv?

# sysctl -a | grep trim
vfs.zfs.vdev.trim_on_init: 1
vfs.zfs.vdev.trim_min_active: 1
vfs.zfs.vdev.trim_max_active: 64
vfs.zfs.vdev.trim_max_bytes: 2147483648
vfs.zfs.vdev.trim_max_pending: 64
vfs.zfs.trim.enabled: 1
vfs.zfs.trim.txg_delay: 32
vfs.zfs.trim.timeout: 30
vfs.zfs.trim.max_interval: 1
kstat.zfs.misc.zio_trim.bytes: 7397738045440
kstat.zfs.misc.zio_trim.success: 328329844
kstat.zfs.misc.zio_trim.unsupported: 1611
kstat.zfs.misc.zio_trim.failed: 0

 

[Koffein71]

Bei mir sieht es so aus:

xxx@vm-freebsd10:~ % sysctl -a | grep trim
vfs.zfs.trim.max_interval: 1
vfs.zfs.trim.timeout: 30
vfs.zfs.trim.txg_delay: 32
vfs.zfs.trim.enabled: 1
vfs.zfs.vdev.trim_max_pending: 10000
vfs.zfs.vdev.trim_max_active: 64
vfs.zfs.vdev.trim_min_active: 1
vfs.zfs.vdev.trim_on_init: 1
kstat.zfs.misc.zio_trim.failed: 0
kstat.zfs.misc.zio_trim.unsupported: 419
kstat.zfs.misc.zio_trim.success: 0
kstat.zfs.misc.zio_trim.bytes: 0

Alles fein. Allerdings

xxx@vm-freebsd10:~ % zfs get compression
NAME  PROPERTY  VALUE  SOURCE
bootpool  compression  off  default
zroot  compression  lz4  local
zroot/ROOT  compression  lz4  inherited from zroot
zroot/ROOT/default  compression  lz4  inherited from zroot
zroot/tmp  compression  lz4  inherited from zroot
zroot/usr  compression  lz4  inherited from zroot
zroot/usr/home  compression  lz4  inherited from zroot
zroot/usr/ports  compression  lz4  inherited from zroot
zroot/usr/src  compression  lz4  inherited from zroot
zroot/var  compression  lz4  inherited from zroot
zroot/var/audit  compression  lz4  inherited from zroot
zroot/var/crash  compression  lz4  inherited from zroot
zroot/var/log  compression  lz4  inherited from zroot
zroot/var/mail  compression  lz4  inherited from zroot
zroot/var/tmp  compression  lz4  inherited from zroot

Also Kompression aktiv. Der Tip von Azazyel also nicht praktikabel.

Na gut. Egal. Wenn 11.0 rauskommt, werde ich vielleicht eine VM frisch aufsetzen.
Aus Interesse habe ich mal schnell 11-RC1 auf einem USB3 Stick installiert. Sieht soweit schon manierlich aus.

Gruß
Koffein71

 

[TCM]

Du kannst auch ein Dataset ohne compression anlegen und das füllen. Das füllt ja dann trotzdem den Pool.

 

[Koffein71]

Das hatte ich mir auch schon mal überlegt.
Heute habe ich das gemacht, aber ohne Erfolg. Das Vollschreiben des Datasets hat ein bisschen gedauert.
Bei Füllstand > 95% wurde die VM richtig unresponsiv. Letztlich hat das VM Image dabei seine maximal erlaubte Größe erreicht.
Nach dem Löschen des Datasets brachte das erneute Shrinken aber keine Verkleinerung der Imagedatei.
Pech gehabt. Aber egal, es kommt mit 11.0 wohl eine neue VM daher. Vielleicht sogar wieder eine richtige Dualboot Installation neben Windows 7.