VM Images auf Btrfs

jb_alvarado

Lieutenant
Registriert
Sep. 2015
Beiträge
617
Hallo Allerseits,
hat von euch jemand Erfahrung mit VMs deren Images auf Btrfs liegen?

Man sagt ja, dass es nicht so optimal ist, große Images auf einem CoW Filesystem zu haben, aber ist das wirklich so gravierend?
Mir geht es bei Btrfs hauptsächlich um die Kompression, die ich dort nutzen möchte. Wenn ich dabei ein paar Prozent Geschwindigkeit verlieren würde, könnte ich noch damit leben. Das Filesystem liegt eh auf einer NVMe.

Wie denkt ihr darüber?
 
Habe ein Desktop System, ohne ECC Ram. Die VMs sind auch nur fürs Entwickeln und zum testen.
 
Zuletzt bearbeitet:
jb_alvarado schrieb:
Habe ein Desktop System, ohne ECC Ram. Die VMs sind auch fürs Entwickeln und zum testen.

Du kannst doch ein eigenes Subvolume in BTRFS anlegen, in dem du CoW ausschaltest und die VMs da hinein legen.
 
Damit würde ich aber genau das verlieren, was ich haben möchte, nämliche die Kompression.
 
Ja in diesem Fall geht es mir wirklich nur um die Kompression. Hatte oben das Wörtchen nur vergessen. Also die VMs gebrauche ich ausschließlich zum Testen und zum Entwickeln.

Manchmal muss ich größere Images anlegen, weil das so von der Software Verlangt wird, aber effektive brauche ich nur ein Bruchteil von der Größe. Daher ist mir die Kompression wichtig.
 
> aber ist das wirklich so gravierend?
HDD, ja Problem ist halt die Fragmentierung.
SSD, geht so.
Geht es dir darum die Daten in der VM komprimiert zu haben oder nur das eine hauptsächlich leeres Image nicht die leeren blocke auf dem Host-system zu belegen?


> Manchmal muss ich größere Images anlegen, weil das so von der Software Verlangt wird, aber effektive brauche ich nur ein Bruchteil von der Größe. Daher ist mir die Kompression wichtig.
DU willst du qcow und kein cow von btrfs.
" One of the main characteristics of qcow disk images is that files with this format can grow as data is added. This allows for smaller file sizes than raw disk images, which allocate the whole image space to a file, even if parts of it are empty. "
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: jb_alvarado und snaxilian
Bringt die wirklich so viel? Ich glaube solange du keine Snapshots erstellst soll das CoW kein Problem sein. Ab und zu ein Defrag und gut ist.
 
Ich raffs auch irgendwie nicht. Wenn ich ein 100 GB image erstelle und dadrauf Windows installiere, ist das Image ca. 15 GB groß auf der Platte, also genauso wie Windows den Speicher eingenommen hat und in Windows sind trz. noch 85 frei... Das ist doch vollkommen normal 🤷‍♂️
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: snaxilian
jb_alvarado schrieb:
Damit würde ich aber genau das verlieren, was ich haben möchte, nämliche die Kompression.
Was hat das eine mit dem anderen zu tun? Du kannst in subvolumes CoW ausschalten, aber kompression ganz normal anlassen.
 
Multivac schrieb:
Geht es dir darum die Daten in der VM komprimiert zu haben oder nur das eine hauptsächlich leeres Image nicht die leeren blocke auf dem Host-system zu belegen?

Im Idealfall beides. Ich verwende auch das qcow2 Image Format, wobei ich die tatsächliche Größe nicht geprüft hatte. Habe mich da von Gnome Files etwas täuschen lassen, weil dort die Größe angezeigt wird, die das Image voll belegt haben wird.

Ich hatte aber auch das Problem, dass mir virt-manager das Erstellen größerer Images verweigert hat, wegen Platzmangel, obwohl ja das Image noch leer ist.

majusss schrieb:
Ich raffs auch irgendwie nicht. Wenn ich ein 100 GB image erstelle und dadrauf Windows installiere, ist das Image ca. 15 GB groß auf der Platte, also genauso wie Windows den Speicher eingenommen hat und in Windows sind trz. noch 85 frei... Das ist doch vollkommen normal 🤷‍♂️

Ja das stimmt auch, aber mit der Zeit wächst das Image, wenn man immer wieder Dateien anlegt und löscht, auch beim Snapshot erstellen und löschen.
 
Deeen schrieb:
Ab und zu ein Defrag und gut ist.

Es gibt ja die Mount-Option autodefrag -> ist die empfehlenswert?

Edit: Sorry, habe zu schnell gefragt... habe gerade gelesen, dass man bei SSDs das nicht setzten darf.
 
Zurück
Oben