Container unter BTRFS

[Mathias R]

Hallo,
sofern die Container auf Datenträgern mit ext4 liegen und in den Containern ebenfalls ext4 zum Einsatz kommt werden Schreib- und Lesevorgänge wegen des doppelten Journaling in Host und Client unnötig langsam.
Mit BTRFS legt Proxmox 7 zwar jeweils ein neues Subvol an, speichert dort jedoch wieder eine RAW Datei mit einem internen ext4 Dateisystem.
Habe ich hier nicht auch wieder eine Verzögerung durch Journaling im ext4 und Copy-on-Write auf dem BTRFS-Drive?

Vielen Dank,
Mathias

 

[floh8]

i think, every layer with a new filesystem make the writes slower.

 

[Dunuin]

Ich denke wenn du BTRFS benutzt ist das journaling von ext4 dein kleinstes Problem. Jedenfalls verursacht ZFS mit CoW und den ganzen Metadaten die mit mehreren Kopien gespeichert werden ein vielfaches des Overheads von ext4 mit aktivem Journaling. Da sollte es ja bei BTRFS nicht viel anders sein.

 

[Mathias R]

BTRFS ist an der Stelle angeblich wesentlich Ressourcenschonender als ZFS. Hierzu gibt es auch diverse Tests.
So ergibt sich für mich die Frage wie man die IO-Last durch das doppelte Journaling optimal vermeiden kann. Könnte man z.B. die Subvolumes von BTRFS direkt durchreichen statt ein RAW File darauf anzulegen? Bei XFS läuft es doch auch so ähnlich.

 

[floh8]

ich finde es höchst interessant, dass bei ext4,btrfs,lvm etc. ein raw-file angelegt wird, aber zfs wird direkt durchgereicht. muss wohl irgendwie an der technologie, rechteproblem, etc. liegen.
man stellt immer wieder fest, wie geil zfs ist, aber es kann halt nicht clustern

 

[Dunuin]

ich finde es höchst interessant, dass bei ext4,btrfs,lvm etc. ein raw-file angelegt wird, aber zfs wird direkt durchgereicht. muss wohl irgendwie an der technologie, rechteproblem, etc. liegen.
man stellt immer wieder fest, wie geil zfs ist, aber es kann halt nicht clustern

Bei LVM wird doch auch ein eigenes LV als Blockdevice erzeugt und dann durchgereicht und nicht nur bei ZFS. Bei ext4 geht das natürlich nicht, das ist ja nur ein einfaches Dateisystem und keine Dateisystem-Raid-Volume-Manager-Kombination wie ZFS/LVM und kann deshalb nicht mit Blockdevices umgehen. Bin auch etwas verwundert das BTRFS nicht mit Blockdevices umgehen kann aber das scheint es wirklich technisch einfach nicht zu können:

Can we create virtual block device in BTRFS?​

No. Btrfs doesn't support the creation of virtual block devices or other non-btrfs filesystems within its managed pool of space.

 

[floh8]

also wenn man über die gui so einen mountpoint einrichtet, erstellt proxmox auch bei lvm ein raw-image. das macht proxmox sicherlich bewusst. dies deckt sich auch mit der doku. nur bei zfs steht subvol. merkwürdiger weise bei DIR auch, aber das ist wohl ein druckfehler

 

[Mathias R]

Dann bleibt nur die Frage wie man das doppelte Journaling verhindert. Man könnte entweder die RAW-Files mit den ext4 Laufwerken auf ein ext2 Laufwerk des Hosts ablegen oder alternativ in den Containern ext2 verwenden. Notfalls auch über MountPoints Teile der Host-Festplatte durchreichen. Das Proxmox per default hier ein eingebautes IO-Problem mitbringt finde ich nicht so toll.

 

[wbumiller]

Im moment werden subvolumes direkt ohne ext4 image nur dann verwendet, wenn man kein Größenlimit verwendet (wie beim normalen directory storage), da man sonst btrfs quotas benutzen muss, was bis noch nicht implementiert ist.
Geht derzeit allerdings nur via CLI (0 als Größe angeben: pct create 123 store:vztmpl/debian-11...tar.gz --rootfs mybtrfsstore:0 ...).

 

[Mathias R]

Super, vielen Dank.
Damit wäre dieses Problem aus meiner Sicht auch gelöst.

Mathias

 

[lonsimbt]

Im moment werden subvolumes direkt ohne ext4 image nur dann verwendet, wenn man kein Größenlimit verwendet (wie beim normalen directory storage), da man sonst btrfs quotas benutzen muss, was bis noch nicht implementiert ist.
Geht derzeit allerdings nur via CLI (0 als Größe angeben: pct create 123 store:vztmpl/debian-11...tar.gz --rootfs mybtrfsstore:0 ...).

@wbumiller
Was ist denn der richtige Weg einen bestehenden Container von einem ext4-image in ein subvolume zu transferieren? Ich hatte es mit einem Backup und dann Wiederherstellung mit

pct restore 123 /Backup/dump/vzdump-lxc-...tar.zstd --rootfs mybtrfsstore:0

versucht. Das hat aber den Container nicht richtig wiederhergestellt. Er startet zwar, ich konnte mich zwar mit root aber keinem der lokalen Nutzer anmelden. Die installierten Dienste starteten nicht.

Gruß Marco

 

[lonsimbt]

Ich habe jetzt mal versucht einen frischen Container auf die von @wbumiller vorgeschlagene Art zu erstellen. Dies führt zu ähnlichen Problemen:

Neuen Container erstellt via

pct create 898 local-btrfs:vztmpl/debian-11-standard_11.0-1_amd64.tar.gz --rootfs local-btrfs:0 --password #### --ostype debian --net0 name=eth0,bridge=vmbr0,ip=dhcp --hostname test --feature nesting=1 --cores 2

Anschließend root-Passwort gesetzt.

"apt update" führt zu Warnungen:

W: Download is performed unsandboxed as root as file '/var/lib/apt/lists/partial/ftp.debian.org_debian_dists_bullseye_InRelease' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)

Neuen Benuter "lonsing" anlegen. Loginversuch führt zu Fehlermeldung und Abbruch des Loginprozesses:

Unable to cd to '/home/lonsing'

Journalctl sagt:

    Sep 25 11:09:14 test login[1518]: pam_unix(login:session): session opened for user lonsing(uid=1000) by LOGIN(uid=0)
    Sep 25 11:09:14 test login[1518]: pam_systemd(login:session): Failed to create session: Seat has no VTs but VT number not 0
    Sep 25 11:09:14 test login[1523]: unable to cd to `/home/lonsing' for user `lonsing'
    Sep 25 11:09:14 test login[1518]: pam_unix(login:session): session closed for user lonsing

 

[hhhkroon]

Entschuldige mein Deutsch. Hab aber keine anliche thread ins English gefunden die night schon einige Jahren alt ist.

Nach einige Jahre sehr zufrieden systemd-nspawn und btrfs benutzt zu haben, verzuche ich jetzt proxmox lxc mit btrfs und hab die gleiche swierigkeiten wie @lonsimbt. Mir fiel ausserdem auf das eine bind-mounted btrfs subvolume auch night zuganglich ist fur non-root user. Eine container mit "dir" type rootfs functioniert aber ohne Problemem.

Da vielen mich die filesystem access rights auf wenn man ein btrfs type container kreiert.

# ls -lad /var/lib/pve/local-btrfs/images/100/subvol-100-disk-0.subvol
drwx------ 1 root root 132 Jan  5 17:14 /var/lib/pve/local-btrfs/images/100/subvol-100-disk-0.subvol

Nach ein chmod +rx functionier dem container dan normal. Services starten und mein non-root user kan einloggen.

# chmod +rx /var/lib/pve/local-btrfs/images/100/subvol-100-disk-0.subvol
# ls -lad /var/lib/pve/local-btrfs/images/100/subvol-100-disk-0.subvol
drwxr-xr-x 1 root root 132 Jan  5 17:14 /var/lib/pve/local-btrfs/images/100/subvol-100-disk-0.subvol

Nach vorbild von @wbumiller / @lonsimbt wurde das dan:

# pct create 898 local-btrfs:vztmpl/debian-11-standard_11.0-1_amd64.tar.gz --rootfs local-btrfs:0 --password --ostype debian --net0 name=eth0,bridge=vmbr0,ip=dhcp --hostname test --feature nesting=1 --cores 2
<SNIP/>
# pct start 898
# pct enter 898
root@test:~# apt update
<SNIP>
34 packages can be upgraded. Run 'apt list --upgradable' to see them.
W: Download is performed unsandboxed as root as file '/var/lib/apt/lists/partial/ftp.debian.org_debian_dists_bullseye_InRelease' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied)
root@test:~# 
exit
# pct stop 898
# chmod +rx /var/lib/pve/local-btrfs/images/898/subvol-898-disk-0.subvol
# pct start 898
# pct enter 898
root@test:~# apt update
<SNIP>
34 packages can be upgraded. Run 'apt list --upgradable' to see them.
root@test:~#

Note dem pkgAcquire::Run (13: Permission denied) for dem chmod +rx des container root.