habe das für meine WindowsVMs schon öfter gemacht, jetzt zum 1.Mal für Linux Mint.

die vdisk hatte 30GB und jetzt 40GB

folgende Anzeige verwirrt mich ...

innerhalb von Linux sieht es aber gut aus ...

einfach ignorieren oder stimmt da was nicht?

Edited October 28, 2025Oct 28 by Cpt.Hardy

Das eine ist das was die VM verwenden kann, das andere die tatsächliche Belegung auf dem Datenträger. Du kannst die Größe sogar nachträglich verkleinern:

• stoppe die VM

• Führe folgendes Kommando aus

fallocate --dig-holes /path/to/vdisk.img

Dadurch wird die Datei "sparse" (schlank). Das Kommando legt dazu Bereiche zusammen, die nur aus Nullen bestehen (= leer sind). Es ist eine Art "Komprimierung", wobei das direkt im Dateisystem passiert und daher keine zusätzliche Rechenleistung bedarf, wenn auf die Daten zugegriffen wird. Das Dateisystem merkt sich dann nicht z.B. NUL, NUL, NUL, NUL, ..., sondern nur ein Kürzel dafür wie z.B. 100xNUL.

Insbesondere wenn man Backups macht, spart man dadurch natürlich massig Platz (vorausgesetzt die Kopier-Kommandos haben sparsiges Kopieren aktiv wie z.B. cp --sparse=always oder rsync --sparse.

Was gegen Sparse spricht:

Man kann übersehen, dass in Summe alle VMs eigentlich mehr Speicherplatz nutzen könnten als der Datenträger überhaupt bereitstellen kann. Also hat man z.B. 2x 500GB VMs, deren Sparse-Größe nur 100GB beträgt. Außerdem hat man die auf einem kleineren Datenträger mit gerade mal 256GB liegen. Nun schreiben die VMs mit der Zeit mehr und mehr Dateien. Das kann dann mit der Zeit dazu führen, dass der Datenträger bis zum letzten Byte vollgeschrieben wird und die VMs schmieren ab. Ein ähnliches Szenario hat man, wenn man parallel auf dem Datenträger Docker Container hat. Also man weiß faktisch nie, wie viel Platz effektiv belegt werden könnte. Man muss es sich also schlicht selbst merken / prüfen.

Das Gegenteil des oben genannten Kommandos wäre (VM ebenfalls stoppen!):

cp -v --sparse=never  /path/to/vdisk.img  /path/to/vdisk.img.copy
mv -v /path/to/vdisk.img.copy /path/to/vdisk.img

(es geht auch mit fallocate -l 60G vdisk.img, aber wenn die Größe versehentlich zu klein angegeben wird, wird das img eiskalt abgeschnitten und Daten gehen verloren. cp ist da deutlich sicherer, aber erfordert auch doppelten Speicherplatz während dem Kopieren).

Ich persönlich bin ein Fan von sparse.

naja, ich habe die vdisk ja extra vergrössert, um LINUX mehr Platz einzuräumen, denn bei updates kam jetzt zuletzt immer schon ein Hinweis auf Platzmangel.

Also, muß ich jetzt noch etwas tun? Ich will da nichts verkleinern sondern den gesamten vdisk Platz von 40gb auch zuweisen.

doppelter Speicher von 40gb während des kopieren ist kein Problem.

Aber wenn ich statt dessen fallocate verwende, kann ja nichts abgeschnitten werden wenn ich von 30gb auf 40gb vergrössere, oder?

Edited November 11, 2025Nov 11 by Cpt.Hardy

hole die Frage nochmals hervor, vielleicht kennt jemand eine Antwort?