[SOLVED] VM-Speicherbedarf laut ZFS anders als laut VM?

R

r4dh4l

Active Member
Proxmox Subscriber
Feb 5, 2018
88
7
28
Hallo,

ich habe folgendes Problem mit meinem Proxmox-Hyperversor unter...

Code: 
# pveversion
pve-manager/5.4-13/aee6f0ec (running kernel: 4.15.18-24-pve)
#

...mit 4x3TB-HDDs im Raid-Z2-Verbund. Eine VM, die für den Datencloud-Serverdienst "Seafile" nutze, belegt meinem Eindruck nach zu viel Platz. Hier die Hypervisor-Sicht:

Code: 
# df -h
Filesystem        Size  Used Avail Use% Mounted on
udev              7.6G     0  7.6G   0% /dev
tmpfs             1.6G   21M  1.5G   2% /run
rpool/ROOT/pve-1   44G  6.5G   37G  15% /
tmpfs             7.6G   34M  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              37G  128K   37G   1% /rpool
rpool/ROOT         37G  128K   37G   1% /rpool/ROOT
rpool/data         37G  128K   37G   1% /rpool/data
/dev/fuse          30M   48K   30M   1% /etc/pve
tmpfs             1.6G     0  1.6G   0% /run/user/1001
# zpool status
  pool: rpool
state: ONLINE
  scan: scrub repaired 0B in 60h40m with 0 errors on Tue Jan 14 13:04:18 2020
config:

        NAME                              STATE     READ WRITE CKSUM
        rpool                             ONLINE       0     0     0
          raidz2-0                        ONLINE       0     0     0
            wwn-0x50014ee0aeffd2a3-part2  ONLINE       0     0     0
            wwn-0x50014ee20a994052-part2  ONLINE       0     0     0
            wwn-0x50014ee2b8e68c1d-part2  ONLINE       0     0     0
            wwn-0x50014ee2ba1acc4e-part2  ONLINE       0     0     0

errors: No known data errors
# zpool list
NAME    SIZE  ALLOC   FREE  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
rpool  10.9T  10.5T   424G         -    45%    96%  1.00x  ONLINE  -
# zfs list
NAME                       USED  AVAIL  REFER  MOUNTPOINT
rpool                     5.07T  37.0G   140K  /rpool
rpool/ROOT                6.50G  37.0G   140K  /rpool/ROOT
rpool/ROOT/pve-1          6.50G  37.0G  6.50G  /
rpool/data                5.05T  37.0G   140K  /rpool/data
rpool/data/vm-101-disk-1  18.9G  37.0G  18.9G  -
rpool/data/vm-101-disk-2  4.91T  37.0G  4.91T  -
rpool/data/vm-103-disk-1  8.03G  37.0G  8.03G  -
rpool/data/vm-104-disk-1  9.47G  37.0G  9.47G  -
rpool/data/vm-104-disk-2  65.6G  37.0G  65.6G  -
rpool/data/vm-105-disk-1  5.45G  37.0G  5.45G  -
rpool/data/vm-106-disk-0  6.45G  37.0G  6.45G  -
rpool/data/vm-107-disk-0  8.40G  37.0G  8.40G  -
rpool/data/vm-108-disk-0  8.52G  37.0G  8.52G  -
rpool/data/vm-109-disk-0  7.13G  37.0G  7.13G  -
rpool/data/vm-110-disk-1  6.20G  37.0G  6.20G  -
rpool/swap                9.12G  37.0G  9.12G  -
#

Es geht um

Code: 
rpool/data/vm-101-disk-2  4.91T  37.0G  4.91T  -

Die VM benötigt also 4.91TB.

Auf Sicht ovn VM-101 ist der Speicherbedarf folgender:

Code: 
# 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  6.1G  8.3G  43% /
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/datapartition             3.5T  2.1T  1.2T  64% /mnt/datapartition
#

Zum historischen Hintergrund: Die VM belegte durchaus mal so viel Platz wie angezeigt. Um bei Seafile Platz zu schaffen, muss ein sogenannter "Garbage Collector" gestartet werden, um nicht mehr genutzte Dateiblöcke zu löschen. Das habe ich neulich gemacht und dabei ca. 1TB Platz gewonnen, zumindest laut VM-Sicht.

Snapshots habe ich für die besagte VM keine.

Warum benötigt VM-101 immernoch 4.91TB?
 
Last edited:
Hi,

du musst in der VM fstrim aufrufen um die früher belegten Blocke frei zu geben.
Wichtig ist dabei das du in der HW config der VM der vdisk die Option discard aktivierst.
sonst werden die umap befehle nicht zu ZFS weitergegeben.
 
  • Like
Reactions: r4dh4l
Danke für die Hilfe!

wolfgang said:
du musst in der VM fstrim aufrufen um die früher belegten Blocke frei zu geben.
Wichtig ist dabei das du in der HW config der VM der vdisk die Option discard aktivierst.
sonst werden die umap befehle nicht zu ZFS weitergegeben.
Click to expand...

Ich habe "discard" in der HW-Config der VM aktiviert (für andere: VM muss heruntergefahren und neu gestartet werden, nicht nur rebooten), aber fstrim meldet:

Code: 
root@vm-seafile:~# fstrim -v /mnt/datapartition
fstrim: /mnt/datapartition: the discard operation is not supported
root@vm-seafile:~#

Liegt es eventuell daran, dass die Partition mit cryptLUKS verschlüsselt ist? Eine kurze Recherche ergab, dass ich in so einem Fall /etc/crypttab/ mofifizieren muss, die ist aber auf der betroffenen VM leer:

Code: 
root@vm-seafile:~# cat /etc/crypttab
# <target name> <source device>         <key file>      <options>
root@vm-seafile:~#
 
r4dh4l said:
Liegt es eventuell daran, dass die Partition mit cryptLUKS verschlüsselt ist?
Click to expand...
Ja das liegt in dem Fall auch noch daran.
Hätte aber ohne die vorherige Änderung auch nicht funktioniert.

Wie du die Mount-Option discard für die crypto Partition aktivierst hängt vom OS(Distribution) und bootloader ab.
 
wolfgang said:
Ja das liegt in dem Fall auch noch daran.
Hätte aber ohne die vorherige Änderung auch nicht funktioniert.

Wie du die Mount-Option discard für die crypto Partition aktivierst hängt vom OS(Distribution) und bootloader ab.
Click to expand...

Danke für die Rückmeldung. Die VM läuft unter Debian9 und der Bootloader ist grub.

Ich habe folgende Einstellungen auf der VM vorgenommen:


Code: 
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 
└─data                    254:2    0  3.5T  0 crypt /mnt/data
root@vm-seafile:~#

root@vm-seafile:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/vm--tmplt--deb9--vg-root /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sda1 during installation
UUID=46e5a17d-b2b6-45f6-8017-063774843f42 /boot           ext2    defaults        0       2
/dev/mapper/vm--tmplt--deb9--vg-swap_1 none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0
/dev/mapper/data /mnt/data ext4 defaults,users,noauto,exec,discard 0 0

root@vm-seafile:~# cat /etc/crypttab
# <target name> <source device> <key file> <options>
data /dev/sdb1 none luks,noauto,discard

root@vm-seafile:~# cat /etc/lvm/lvm.conf | grep issue_discard
        # Configuration option devices/issue_discards.
        #issue_discards = 0
        issue_discards = 1
root@vm-seafile:~#

ich habe die VM neu gestartet, bekomme jedoch leider immernoch:

Code: 
root@vm-seafile:~# fstrim -v /mnt/data
fstrim: /mnt/data: the discard operation is not supported
root@vm-seafile:~#

Muss ich proxmox-seitig noch irgendetwas einstellen?
 
Du musst auf Proxmox VE Seite nur die discard option bei der vdisk setzen.
und das Storage muss das unterstützen.
Also in deinem Fall sollte zfs sagen "reservation none"
Code: 
zfs get reservation rpool/data/vm-101-disk-1
 
wolfgang said:
Du musst auf Proxmox VE Seite nur die discard option bei der vdisk setzen.
und das Storage muss das unterstützen.
Also in deinem Fall sollte zfs sagen "reservation none"
Code: 
zfs get reservation rpool/data/vm-101-disk-1
Click to expand...

Danke, sollte der Fall sein:


Code: 
root@proxmox:~# zfs get reservation rpool/data/vm-101-disk-1
NAME                      PROPERTY     VALUE   SOURCE
rpool/data/vm-101-disk-1  reservation  none    default
root@proxmox:~# zfs get reservation rpool/data/vm-101-disk-2
NAME                      PROPERTY     VALUE   SOURCE
rpool/data/vm-101-disk-2  reservation  none    default
root@proxmox:~# qm config 101
agent: 1
autostart: 1
bootdisk: scsi0
cores: 1
description: ide2%3A local%3Aiso/debian-9.3.0-amd64-netinst.iso,media=cdrom%0Aide3%3A /dev/sdf1
memory: 2048
name: vm-seafile
net0: virtio=5E:2D:ED:2E:D3:AA,bridge=vmbr0
numa: 0
onboot: 1
ostype: l26
protection: 1
scsi0: local-zfs:vm-101-disk-1,size=16G
scsi1: local-zfs:vm-101-disk-2,discard=on,size=3584G
scsihw: virtio-scsi-pci
smbios1: uuid=e3827c0b-c1ec-41d1-9b90-14bd281f08e1
sockets: 1
startup: order=6,up=90
root@proxmox:~#

Aber:

Code: 
root@vm-seafile:~# fstrim -v /mnt/data
fstrim: /mnt/data: the discard operation is not supported
root@vm-seafile:~#

(wobei /mnt/data dem entspricht, was proxmox-seitig local-zfs:vm-101-disk-2 ist)
 
Last edited:
Hätte noch jemand eine Idee zu dieser Problematik?

Problem war und ist, dass sich in der VM fstrim nicht aufrufen lässt, um frei gewordenen Speicher freizugeben, obwohl die Discard-option für die betroffene Partition gesetzt wurde und "zfs get reservation" bestätigt, dass es möglich sein müsste ("reservation none").
 
Last edited:
Die Lösung findet sich hier. Kurzum: Wenn man eine verschlüsselte Disk manuell entsperrt, werden die Discard-Optionen aus crypttab/fstab nicht übernommen und man muss "cryptsetup luksOpen" den Paraemeter "--allow-discards" mitgeben.
 
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
Back