Grote crash filesystem na toevoegen swap / diagnose?

[vmsw]

Mijn vraag
Vanmorgen enorme crash van virtuele host (Proxmox Linux KVM server), vrij snel nadat ik extra swap had toegevoegd omdat ik zag dat hij relatief weinig had (maar in principe was er geen acute nood/reden toe)

Mijn vraag: weet iemand wat er mis ging en/of hoe ik hiertoe kan komen? Want de impact was enorm, en ik weet niet eens wat er mis ging c.q. of die server nog wel te vertrouwen is (nadat alles hersteld is)


Bash-log van mijn acties die (mogelijk/vermoedelijk) geleid hebben tot crash:

code:

Linux vrt14 5.0.21-5-pve #1 SMP PVE 5.0.21-10 (Wed, 13 Nov 2019 08:27:10 +0100) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Sep 20 08:15:28 2021 from 145.131.206.197
username@vrt14:~$ htop
username@vrt14:~$ cd /ssd
username@vrt14:/ssd$ sudo su
[sudo] password for username:
root@vrt14:/ssd# df -h
Filesystem                       Size  Used Avail Use% Mounted on
udev                             126G     0  126G   0% /dev
tmpfs                             26G  2.6G   23G  11% /run
/dev/mapper/pve-root             7.1G  4.4G  2.4G  65% /
tmpfs                            126G   63M  126G   1% /dev/shm
tmpfs                            5.0M     0  5.0M   0% /run/lock
tmpfs                            126G     0  126G   0% /sys/fs/cgroup
/dev/mapper/vg--ssd-ssd          1.8T  1.5T  280G  85% /ssd
/dev/sda2                        253M  288K  252M   1% /boot/efi
192.168.30.13:/virtual-backups   6.0T  5.2T  770G  88% /mnt/pve/virtual-backups
192.168.30.13:/virtual-storage   6.9T  6.6T  361G  95% /mnt/pve/virtual-storage
192.168.30.13:/virtual-machines  4.0T  633G  3.4T  16% /mnt/pve/virtual-machines
/dev/fuse                         30M  108K   30M   1% /etc/pve
/dev/sda4                        190G   17G  164G   9% /root2
tmpfs                             26G     0   26G   0% /run/user/1000
root@vrt14:/ssd# cd /ssd
root@vrt14:/ssd# ls
images  lost+found
root@vrt14:/ssd# fallocate -l 16G swapfile
root@vrt14:/ssd# chmod 600 swapfile
root@vrt14:/ssd# mkswap swapfile
Setting up swapspace version 1, size = 16 GiB (17179865088 bytes)
no label, UUID=d6351852-811f-44e4-9237-90d8809dd31e
root@vrt14:/ssd# swapon swapfile
root@vrt14:/ssd# nano /etc/fstab
root@vrt14:/ssd# swapon
NAME            TYPE      SIZE USED PRIO
/dev/dm-1       partition 3.6G 3.6G   -2
/root2/swapfile file       16G  16G   -3
/ssd/swapfile   file       16G 3.7G   -4

Wat er gebeurde is dat alle vm's (die ook op /ssd staan) een crash gaven.

code:

Oct 26 09:23:17 vrt14 systemd[1]: Started User Manager for UID 1000.
Oct 26 09:23:17 vrt14 systemd[1]: Started Session 19945 of user username.
Oct 26 09:24:00 vrt14 systemd[1]: Starting Proxmox VE replication runner...
Oct 26 09:24:01 vrt14 systemd[1]: pvesr.service: Succeeded.
Oct 26 09:24:01 vrt14 systemd[1]: Started Proxmox VE replication runner.
Oct 26 09:24:56 vrt14 kernel: [60614064.532920] Adding 16777212k swap on /ssd/swapfile.  Priority:-4 extents:23313 across:1875214648k SSFS
Oct 26 09:25:00 vrt14 systemd[1]: Starting Proxmox VE replication runner...
Oct 26 09:25:01 vrt14 systemd[1]: pvesr.service: Succeeded.
Oct 26 09:25:01 vrt14 systemd[1]: Started Proxmox VE replication runner.
Oct 26 09:26:00 vrt14 systemd[1]: Starting Proxmox VE replication runner...
Oct 26 09:26:01 vrt14 systemd[1]: pvesr.service: Succeeded.
Oct 26 09:26:01 vrt14 systemd[1]: Started Proxmox VE replication runner.
Oct 26 09:26:11 vrt14 kernel: [60614139.572133] show_signal_msg: 9 callbacks suppressed
Oct 26 09:26:11 vrt14 kernel: [60614139.572136] kvm[32423]: segfault at 0 ip 00007efc5ca81709 sp 00007efc4ef7a570 error 4 in libjemalloc.so.2[7efc5ca65000+83000]
Oct 26 09:26:11 vrt14 kernel: [60614139.572146] Code: 0f 85 13 02 00 00 48 89 e8 48 c1 e8 09 25 f8 ff 1f 00 48 03 46 08 48 8b 18 4d 8d 5c 24 28 48 c1 e3 10 48 c1 fb 10 48 83 e3 fe <48> 8b 33 48 81 e6 ff ff 03 fc 48 81 ce 00 00 90 00 48 89 33 4d 85
Oct 26 09:26:11 vrt14 kernel: [60614139.616352] fwbr150i1: port 2(tap150i1) entered disabled state
Oct 26 09:26:11 vrt14 kernel: [60614139.616789] fwbr150i1: port 2(tap150i1) entered disabled state
Oct 26 09:26:13 vrt14 kernel: [60614141.492448] fwbr150i0: port 2(tap150i0) entered disabled state
Oct 26 09:26:13 vrt14 kernel: [60614141.492862] fwbr150i0: port 2(tap150i0) entered disabled state
Oct 26 09:26:13 vrt14 systemd[1]: 150.scope: Succeeded.
Oct 26 09:26:14 vrt14 pmxcfs[11901]: [status] notice: received log
Oct 26 09:26:14 vrt14 systemd[1]: Created slice User Slice of UID 0.
Oct 26 09:26:14 vrt14 systemd[1]: Starting User Runtime Directory /run/user/0...
Oct 26 09:26:14 vrt14 systemd[1]: Started User Runtime Directory /run/user/0.
Oct 26 09:26:14 vrt14 systemd[1]: Starting User Manager for UID 0...
Oct 26 09:26:14 vrt14 systemd[33629]: Reached target Timers.
Oct 26 09:26:14 vrt14 systemd[33629]: Starting D-Bus User Message Bus Socket.
Oct 26 09:26:14 vrt14 systemd[33629]: Listening on GnuPG cryptographic agent and passphrase cache.
Oct 26 09:26:14 vrt14 systemd[33629]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
Oct 26 09:26:14 vrt14 systemd[33629]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
Oct 26 09:26:14 vrt14 systemd[33629]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Oct 26 09:26:14 vrt14 systemd[33629]: Listening on GnuPG network certificate management daemon.
Oct 26 09:26:14 vrt14 systemd[33629]: Reached target Paths.
Oct 26 09:26:14 vrt14 systemd[33629]: Listening on D-Bus User Message Bus Socket.
Oct 26 09:26:14 vrt14 systemd[33629]: Reached target Sockets.
Oct 26 09:26:14 vrt14 systemd[33629]: Reached target Basic System.
Oct 26 09:26:14 vrt14 systemd[33629]: Reached target Default.
Oct 26 09:26:14 vrt14 systemd[33629]: Startup finished in 94ms.
Oct 26 09:26:14 vrt14 systemd[1]: Started User Manager for UID 0.
Oct 26 09:26:14 vrt14 systemd[1]: Started Session 19947 of user root.
Oct 26 09:26:14 vrt14 qmeventd[12165]: Starting cleanup for 150
Oct 26 09:26:14 vrt14 kernel: [60614142.302766] fwbr150i0: port 1(fwln150i0) entered disabled state
Oct 26 09:26:14 vrt14 kernel: [60614142.303134] vmbr1: port 3(fwpr150p0) entered disabled state
Oct 26 09:26:14 vrt14 kernel: [60614142.303521] device fwln150i0 left promiscuous mode
Oct 26 09:26:14 vrt14 kernel: [60614142.303523] fwbr150i0: port 1(fwln150i0) entered disabled state
Oct 26 09:26:14 vrt14 kernel: [60614142.345142] device fwpr150p0 left promiscuous mode
Oct 26 09:26:14 vrt14 kernel: [60614142.345146] vmbr1: port 3(fwpr150p0) entered disabled state
Oct 26 09:26:14 vrt14 kernel: [60614142.577896] fwbr150i1: port 1(fwln150i1) entered disabled state
Oct 26 09:26:14 vrt14 kernel: [60614142.578102] vmbr0: port 7(fwpr150p1) entered disabled state
Oct 26 09:26:14 vrt14 kernel: [60614142.578494] device fwln150i1 left promiscuous mode
Oct 26 09:26:14 vrt14 kernel: [60614142.578496] fwbr150i1: port 1(fwln150i1) entered disabled state
Oct 26 09:26:14 vrt14 kernel: [60614142.640537] device fwpr150p1 left promiscuous mode
Oct 26 09:26:14 vrt14 kernel: [60614142.640540] vmbr0: port 7(fwpr150p1) entered disabled state
Oct 26 09:26:15 vrt14 qmeventd[12165]: Finished cleanup for 150
Oct 26 09:26:15 vrt14 qm[33648]: VM 150 qmp command failed - VM 150 not running
Oct 26 09:26:15 vrt14 systemd[1]: session-19947.scope: Succeeded.
Oct 26 09:26:15 vrt14 pmxcfs[11901]: [status] notice: received log
Oct 26 09:26:23 vrt14 pvedaemon[33705]: start VM 150: UPID:vrt14:000083A9:1694AF0AD:6177AD9F:qmstart:150:username@pam:
Oct 26 09:26:23 vrt14 pvedaemon[47689]: <username@pam> starting task UPID:vrt14:000083A9:1694AF0AD:6177AD9F:qmstart:150:username@pam:
Oct 26 09:26:23 vrt14 systemd[1]: Started 150.scope.
Oct 26 09:26:23 vrt14 systemd-udevd[33711]: Using default interface naming scheme 'v240'.
Oct 26 09:26:23 vrt14 systemd-udevd[33711]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Oct 26 09:26:23 vrt14 systemd-udevd[33711]: Could not generate persistent MAC address for tap150i0: No such file or directory
Oct 26 09:26:24 vrt14 kernel: [60614151.785915] device tap150i0 entered promiscuous mode
Oct 26 09:26:24 vrt14 systemd-udevd[33711]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Oct 26 09:26:24 vrt14 systemd-udevd[33711]: Could not generate persistent MAC address for fwbr150i0: No such file or directory
Oct 26 09:26:24 vrt14 systemd-udevd[33715]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Oct 26 09:26:24 vrt14 systemd-udevd[33715]: Using default interface naming scheme 'v240'.
Oct 26 09:26:24 vrt14 systemd-udevd[33714]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Oct 26 09:26:24 vrt14 systemd-udevd[33715]: Could not generate persistent MAC address for fwpr150p0: No such file or directory
Oct 26 09:26:24 vrt14 systemd-udevd[33714]: Using default interface naming scheme 'v240'.
Oct 26 09:26:24 vrt14 systemd-udevd[33714]: Could not generate persistent MAC address for fwln150i0: No such file or directory
Oct 26 09:26:24 vrt14 kernel: [60614151.835721] fwbr150i0: port 1(fwln150i0) entered blocking state
Oct 26 09:26:24 vrt14 kernel: [60614151.835723] fwbr150i0: port 1(fwln150i0) entered disabled state
Oct 26 09:26:24 vrt14 kernel: [60614151.835883] device fwln150i0 entered promiscuous mode
Oct 26 09:26:24 vrt14 kernel: [60614151.835949] fwbr150i0: port 1(fwln150i0) entered blocking state
Oct 26 09:26:24 vrt14 kernel: [60614151.835951] fwbr150i0: port 1(fwln150i0) entered forwarding state
Oct 26 09:26:24 vrt14 kernel: [60614151.841872] vmbr1: port 3(fwpr150p0) entered blocking state
Oct 26 09:26:24 vrt14 kernel: [60614151.841876] vmbr1: port 3(fwpr150p0) entered disabled state
Oct 26 09:26:24 vrt14 kernel: [60614151.842008] device fwpr150p0 entered promiscuous mode
Oct 26 09:26:24 vrt14 kernel: [60614151.842060] vmbr1: port 3(fwpr150p0) entered blocking state
Oct 26 09:26:24 vrt14 kernel: [60614151.842062] vmbr1: port 3(fwpr150p0) entered forwarding state
Oct 26 09:26:24 vrt14 kernel: [60614151.846860] fwbr150i0: port 2(tap150i0) entered blocking state
Oct 26 09:26:24 vrt14 kernel: [60614151.846862] fwbr150i0: port 2(tap150i0) entered disabled state
Oct 26 09:26:24 vrt14 kernel: [60614151.847035] fwbr150i0: port 2(tap150i0) entered blocking state
Oct 26 09:26:24 vrt14 kernel: [60614151.847037] fwbr150i0: port 2(tap150i0) entered forwarding state
Oct 26 09:26:24 vrt14 systemd-udevd[33711]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Oct 26 09:26:24 vrt14 systemd-udevd[33711]: Could not generate persistent MAC address for tap150i1: No such file or directory
Oct 26 09:26:24 vrt14 kernel: [60614152.417563] device tap150i1 entered promiscuous mode
Oct 26 09:26:24 vrt14 systemd-udevd[33711]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Oct 26 09:26:24 vrt14 systemd-udevd[33711]: Could not generate persistent MAC address for fwbr150i1: No such file or directory
Oct 26 09:26:24 vrt14 systemd-udevd[33715]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Oct 26 09:26:24 vrt14 systemd-udevd[33714]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Oct 26 09:26:24 vrt14 systemd-udevd[33714]: Could not generate persistent MAC address for fwln150i1: No such file or directory
Oct 26 09:26:24 vrt14 systemd-udevd[33715]: Could not generate persistent MAC address for fwpr150p1: No such file or directory
Oct 26 09:26:24 vrt14 kernel: [60614152.472309] fwbr150i1: port 1(fwln150i1) entered blocking state
Oct 26 09:26:24 vrt14 kernel: [60614152.472312] fwbr150i1: port 1(fwln150i1) entered disabled state
Oct 26 09:26:24 vrt14 kernel: [60614152.472458] device fwln150i1 entered promiscuous mode
Oct 26 09:26:24 vrt14 kernel: [60614152.472546] fwbr150i1: port 1(fwln150i1) entered blocking state
Oct 26 09:26:24 vrt14 kernel: [60614152.472549] fwbr150i1: port 1(fwln150i1) entered forwarding state
Oct 26 09:26:24 vrt14 kernel: [60614152.481244] vmbr0: port 7(fwpr150p1) entered blocking state
Oct 26 09:26:24 vrt14 kernel: [60614152.481247] vmbr0: port 7(fwpr150p1) entered disabled state
Oct 26 09:26:24 vrt14 kernel: [60614152.481408] device fwpr150p1 entered promiscuous mode
Oct 26 09:26:24 vrt14 kernel: [60614152.481475] vmbr0: port 7(fwpr150p1) entered blocking state
Oct 26 09:26:24 vrt14 kernel: [60614152.481478] vmbr0: port 7(fwpr150p1) entered forwarding state
Oct 26 09:26:24 vrt14 kernel: [60614152.489538] fwbr150i1: port 2(tap150i1) entered blocking state
Oct 26 09:26:24 vrt14 kernel: [60614152.489542] fwbr150i1: port 2(tap150i1) entered disabled state
Oct 26 09:26:24 vrt14 kernel: [60614152.489743] fwbr150i1: port 2(tap150i1) entered blocking state
Oct 26 09:26:24 vrt14 kernel: [60614152.489746] fwbr150i1: port 2(tap150i1) entered forwarding state
Oct 26 09:26:25 vrt14 pvedaemon[47689]: <username@pam> end task UPID:vrt14:000083A9:1694AF0AD:6177AD9F:qmstart:150:username@pam: OK
Oct 26 09:26:25 vrt14 systemd[1]: Stopping User Manager for UID 0...
Oct 26 09:26:25 vrt14 systemd[33629]: Stopped target Default.
Oct 26 09:26:25 vrt14 systemd[33629]: Stopped target Basic System.
Oct 26 09:26:25 vrt14 systemd[33629]: Stopped target Timers.
Oct 26 09:26:25 vrt14 systemd[33629]: Stopped target Paths.
Oct 26 09:26:25 vrt14 systemd[33629]: Stopped target Sockets.
Oct 26 09:26:25 vrt14 systemd[33629]: dirmngr.socket: Succeeded.
Oct 26 09:26:25 vrt14 systemd[33629]: Closed GnuPG network certificate management daemon.
Oct 26 09:26:25 vrt14 systemd[33629]: gpg-agent-extra.socket: Succeeded.
Oct 26 09:26:25 vrt14 systemd[33629]: Closed GnuPG cryptographic agent and passphrase cache (restricted).
Oct 26 09:26:25 vrt14 systemd[33629]: gpg-agent-ssh.socket: Succeeded.
Oct 26 09:26:25 vrt14 systemd[33629]: Closed GnuPG cryptographic agent (ssh-agent emulation).
Oct 26 09:26:25 vrt14 systemd[33629]: gpg-agent-browser.socket: Succeeded.
Oct 26 09:26:25 vrt14 systemd[33629]: Closed GnuPG cryptographic agent and passphrase cache (access for web browsers).
Oct 26 09:26:25 vrt14 systemd[33629]: gpg-agent.socket: Succeeded.
Oct 26 09:26:25 vrt14 systemd[33629]: Closed GnuPG cryptographic agent and passphrase cache.
Oct 26 09:26:25 vrt14 systemd[33629]: dbus.socket: Succeeded.
Oct 26 09:26:25 vrt14 systemd[33629]: Closed D-Bus User Message Bus Socket.
Oct 26 09:26:25 vrt14 systemd[33629]: Reached target Shutdown.
Oct 26 09:26:25 vrt14 systemd[33629]: systemd-exit.service: Succeeded.
Oct 26 09:26:25 vrt14 systemd[33629]: Started Exit the Session.
Oct 26 09:26:25 vrt14 systemd[33629]: Reached target Exit the Session.
Oct 26 09:26:25 vrt14 systemd[1]: [e-mail]: Succeeded.
Oct 26 09:26:25 vrt14 systemd[1]: Stopped User Manager for UID 0.
Oct 26 09:26:25 vrt14 systemd[1]: Stopping User Runtime Directory /run/user/0...
Oct 26 09:26:25 vrt14 systemd[1]: run-user-0.mount: Succeeded.
Oct 26 09:26:25 vrt14 systemd[1]: [e-mail]: Succeeded.
Oct 26 09:26:25 vrt14 systemd[1]: Stopped User Runtime Directory /run/user/0.
Oct 26 09:26:25 vrt14 systemd[32665]: run-user-0.mount: Succeeded.
Oct 26 09:26:25 vrt14 systemd[1]: Removed slice User Slice of UID 0.
Oct 26 09:26:36 vrt14 pmxcfs[11901]: [status] notice: received log
Oct 26 09:26:37 vrt14 systemd[1]: Created slice User Slice of UID 0.
Oct 26 09:26:37 vrt14 systemd[1]: Starting User Runtime Directory /run/user/0...
Oct 26 09:26:37 vrt14 systemd[1]: Started User Runtime Directory /run/user/0.
Oct 26 09:26:37 vrt14 systemd[1]: Starting User Manager for UID 0...
Oct 26 09:26:37 vrt14 systemd[33927]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
Oct 26 09:26:37 vrt14 systemd[33927]: Listening on GnuPG network certificate management daemon.
Oct 26 09:26:37 vrt14 systemd[33927]: Reached target Timers.
Oct 26 09:26:37 vrt14 systemd[33927]: Listening on GnuPG cryptographic agent and passphrase cache.
Oct 26 09:26:37 vrt14 systemd[33927]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
Oct 26 09:26:37 vrt14 systemd[33927]: Starting D-Bus User Message Bus Socket.
Oct 26 09:26:37 vrt14 systemd[33927]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Oct 26 09:26:37 vrt14 systemd[33927]: Reached target Paths.
Oct 26 09:26:37 vrt14 systemd[33927]: Listening on D-Bus User Message Bus Socket.
Oct 26 09:26:37 vrt14 systemd[33927]: Reached target Sockets.
Oct 26 09:26:37 vrt14 systemd[33927]: Reached target Basic System.
Oct 26 09:26:37 vrt14 systemd[33927]: Reached target Default.
Oct 26 09:26:37 vrt14 systemd[33927]: Startup finished in 103ms.
Oct 26 09:26:37 vrt14 systemd[1]: Started User Manager for UID 0.
Oct 26 09:26:37 vrt14 systemd[1]: Started Session 19949 of user root.
Oct 26 09:27:00 vrt14 systemd[1]: Starting Proxmox VE replication runner...
Oct 26 09:27:01 vrt14 systemd[1]: pvesr.service: Succeeded.
Oct 26 09:27:01 vrt14 systemd[1]: Started Proxmox VE replication runner.
Oct 26 09:27:22 vrt14 systemd[1]: session-19949.scope: Succeeded.
Oct 26 09:27:22 vrt14 pmxcfs[11901]: [status] notice: received log
Oct 26 09:27:24 vrt14 pvedaemon[47689]: <username@pam> starting task UPID:vrt14:00008570:1694B08A3:6177ADDC:qmshutdown:150:username@pam:
Oct 26 09:27:24 vrt14 pvedaemon[34160]: shutdown VM 150: UPID:vrt14:00008570:1694B08A3:6177ADDC:qmshutdown:150:username@pam:
Oct 26 09:27:32 vrt14 systemd[1]: Stopping User Manager for UID 0...
Oct 26 09:27:32 vrt14 systemd[33927]: Stopped target Default.
Oct 26 09:27:32 vrt14 systemd[33927]: Stopped target Basic System.
Oct 26 09:27:32 vrt14 systemd[33927]: Stopped target Sockets.
Oct 26 09:27:32 vrt14 systemd[33927]: dbus.socket: Succeeded.
Oct 26 09:27:32 vrt14 systemd[33927]: Closed D-Bus User Message Bus Socket.
Oct 26 09:27:32 vrt14 systemd[33927]: gpg-agent-extra.socket: Succeeded.
Oct 26 09:27:32 vrt14 systemd[33927]: Closed GnuPG cryptographic agent and passphrase cache (restricted).
Oct 26 09:27:32 vrt14 systemd[33927]: gpg-agent.socket: Succeeded.
Oct 26 09:27:32 vrt14 systemd[33927]: Closed GnuPG cryptographic agent and passphrase cache.
Oct 26 09:27:32 vrt14 systemd[33927]: dirmngr.socket: Succeeded.
Oct 26 09:27:32 vrt14 systemd[33927]: Closed GnuPG network certificate management daemon.
Oct 26 09:27:32 vrt14 systemd[33927]: gpg-agent-ssh.socket: Succeeded.
Oct 26 09:27:32 vrt14 systemd[33927]: Closed GnuPG cryptographic agent (ssh-agent emulation).
Oct 26 09:27:32 vrt14 systemd[33927]: Stopped target Timers.
Oct 26 09:27:32 vrt14 systemd[33927]: Stopped target Paths.
Oct 26 09:27:32 vrt14 systemd[33927]: gpg-agent-browser.socket: Succeeded.
Oct 26 09:27:32 vrt14 systemd[33927]: Closed GnuPG cryptographic agent and passphrase cache (access for web browsers).
Oct 26 09:27:32 vrt14 systemd[33927]: Reached target Shutdown.
Oct 26 09:27:32 vrt14 systemd[33927]: systemd-exit.service: Succeeded.
Oct 26 09:27:32 vrt14 systemd[33927]: Started Exit the Session.
Oct 26 09:27:32 vrt14 systemd[33927]: Reached target Exit the Session.
Oct 26 09:27:32 vrt14 systemd[1]: [e-mail]: Succeeded.
Oct 26 09:27:32 vrt14 systemd[1]: Stopped User Manager for UID 0.
Oct 26 09:27:32 vrt14 systemd[1]: Stopping User Runtime Directory /run/user/0...
Oct 26 09:27:32 vrt14 systemd[1]: run-user-0.mount: Succeeded.
Oct 26 09:27:32 vrt14 systemd[32665]: run-user-0.mount: Succeeded.
Oct 26 09:27:32 vrt14 systemd[1]: [e-mail]: Succeeded.
Oct 26 09:27:32 vrt14 systemd[1]: Stopped User Runtime Directory /run/user/0.
Oct 26 09:27:32 vrt14 systemd[1]: Removed slice User Slice of UID 0.
Oct 26 09:27:37 vrt14 pmxcfs[11901]: [status] notice: received log
Oct 26 09:27:37 vrt14 systemd[1]: Created slice User Slice of UID 0.
Oct 26 09:27:37 vrt14 systemd[1]: Starting User Runtime Directory /run/user/0...
Oct 26 09:27:37 vrt14 systemd[1]: Started User Runtime Directory /run/user/0.
Oct 26 09:27:37 vrt14 systemd[1]: Starting User Manager for UID 0...
Oct 26 09:27:37 vrt14 systemd[34267]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
Oct 26 09:27:37 vrt14 systemd[34267]: Listening on GnuPG network certificate management daemon.
Oct 26 09:27:37 vrt14 systemd[34267]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Oct 26 09:27:37 vrt14 systemd[34267]: Listening on GnuPG cryptographic agent and passphrase cache.
Oct 26 09:27:37 vrt14 systemd[34267]: Starting D-Bus User Message Bus Socket.
Oct 26 09:27:37 vrt14 systemd[34267]: Reached target Paths.
Oct 26 09:27:37 vrt14 systemd[34267]: Reached target Timers.
Oct 26 09:27:37 vrt14 systemd[34267]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
Oct 26 09:27:37 vrt14 systemd[34267]: Listening on D-Bus User Message Bus Socket.
Oct 26 09:27:37 vrt14 systemd[34267]: Reached target Sockets.
Oct 26 09:27:37 vrt14 systemd[34267]: Reached target Basic System.
Oct 26 09:27:37 vrt14 systemd[34267]: Reached target Default.
Oct 26 09:27:37 vrt14 systemd[34267]: Startup finished in 83ms.
Oct 26 09:27:37 vrt14 systemd[1]: Started User Manager for UID 0.
Oct 26 09:27:37 vrt14 systemd[1]: Started Session 19951 of user root.
Oct 26 09:27:41 vrt14 pmxcfs[11901]: [status] notice: received log
Oct 26 09:27:42 vrt14 systemd[1]: Started Session 19953 of user root.
Oct 26 09:27:45 vrt14 systemd[1]: session-19953.scope: Succeeded.
Oct 26 09:27:45 vrt14 pmxcfs[11901]: [status] notice: received log
Oct 26 09:28:00 vrt14 systemd[1]: Starting Proxmox VE replication runner...
Oct 26 09:28:00 vrt14 systemd[1]: pvesr.service: Succeeded.
Oct 26 09:28:00 vrt14 systemd[1]: Started Proxmox VE replication runner.
Oct 26 09:28:24 vrt14 pvedaemon[34160]: VM quit/powerdown failed - got timeout
Oct 26 09:28:24 vrt14 pvedaemon[47689]: <username@pam> end task UPID:vrt14:00008570:1694B08A3:6177ADDC:qmshutdown:150:username@pam: VM quit/powerdown failed - got timeout
Oct 26 09:28:34 vrt14 kernel: [60614281.913565] EXT4-fs error (device dm-0): ext4_validate_block_bitmap:376: comm kvm: bg 13924: bad block bitmap checksum
Oct 26 09:28:34 vrt14 pvedaemon[40343]: Can't locate object method "#000#000#000#000#000" via package "URI::_generic" at /usr/share/perl5/URI.pm line 64.
Oct 26 09:28:58 vrt14 systemd[1]: Started Session 19954 of user username.
Oct 26 09:29:00 vrt14 systemd[1]: Starting Proxmox VE replication runner...
Oct 26 09:29:01 vrt14 systemd[1]: pvesr.service: Succeeded.
Oct 26 09:29:01 vrt14 systemd[1]: Started Proxmox VE replication runner.
Oct 26 09:29:03 vrt14 pvedaemon[40343]: Can't locate object method "#000#000#000#000#000" via package "URI::_generic" at /usr/share/perl5/URI.pm line 64.
Oct 26 09:29:15 vrt14 pvedaemon[40343]: Can't locate object method "#000#000#000#000#000" via package "URI::_generic" at /usr/share/perl5/URI.pm line 64.
Oct 26 09:29:21 vrt14 pvedaemon[40343]: Can't locate object method "#000#000#000#000#000" via package "URI::_generic" at /usr/share/perl5/URI.pm line 64.
Oct 26 09:29:22 vrt14 pvedaemon[40343]: Can't locate object method "#000#000#000#000#000" via package "URI::_generic" at /usr/share/perl5/URI.pm line 64.
Oct 26 09:29:23 vrt14 pvedaemon[40343]: Can't locate object method "#000#000#000#000#000" via package "URI::_generic" at /usr/share/perl5/URI.pm line 64.
Oct 26 09:29:40 vrt14 pmxcfs[11901]: [status] notice: received log
Oct 26 09:29:40 vrt14 systemd[1]: Started Session 19955 of user root.
Oct 26 09:29:44 vrt14 pvedaemon[40343]: Can't locate object method "#000#000#000#000#000" via package "URI::_generic" at /usr/share/perl5/URI.pm line 64.
Oct 26 09:29:54 vrt14 pmxcfs[11901]: [status] notice: received log

...

paar min later

...

Oct 26 09:32:56 vrt14 kernel: [60614544.424452] EXT4-fs error (device dm-0): ext4_validate_block_bitmap:376: comm kvm: bg 9043: bad block bitmap checksum
Oct 26 09:32:56 vrt14 kernel: [60614544.424530] EXT4-fs error (device dm-0): ext4_discard_preallocations:4073: comm kvm: Error -74 reading block bitmap for 9043
Oct 26 09:32:56 vrt14 kernel: [60614544.430178] EXT4-fs error (device dm-0): ext4_validate_block_bitmap:376: comm kvm: bg 13310: bad block bitmap checksum
Oct 26 09:32:56 vrt14 kernel: [60614544.430239] EXT4-fs error (device dm-0): ext4_discard_preallocations:4065: comm kvm: Error -74 loading buddy information for 13310
Oct 26 09:32:56 vrt14 kernel: [60614544.435025] EXT4-fs error (device dm-0): ext4_validate_block_bitmap:376: comm kvm: bg 9047: bad block bitmap checksum
Oct 26 09:32:56 vrt14 kernel: [60614544.435090] EXT4-fs error (device dm-0): ext4_discard_preallocations:4065: comm kvm: Error -74 loading buddy information for 9047
Oct 26 09:32:56 vrt14 kernel: [60614544.435335] EXT4-fs error (device dm-0): ext4_validate_block_bitmap:376: comm kvm: bg 9048: bad block bitmap checksum
Oct 26 09:32:56 vrt14 kernel: [60614544.435390] EXT4-fs error (device dm-0): ext4_discard_preallocations:4065: comm kvm: Error -74 loading buddy information for 9048
Oct 26 09:32:56 vrt14 kernel: [60614544.438149] EXT4-fs error (device dm-0): ext4_validate_block_bitmap:376: comm kvm: bg 13299: bad block bitmap checksum
Oct 26 09:32:56 vrt14 kernel: [60614544.438206] EXT4-fs error (device dm-0): ext4_discard_preallocations:4073: comm kvm: Error -74 reading block bitmap for 13299

...

reboot

...

Oct 26 09:56:51 vrt14 kernel: [  176.072902] EXT4-fs error (device dm-0): ext4_find_extent:913: inode #44957706: comm kvm: pblk 234161639 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Oct 26 09:56:51 vrt14 kernel: [  176.073883] EXT4-fs error (device dm-0): ext4_find_extent:913: inode #44957706: comm kvm: pblk 234161639 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Oct 26 09:56:51 vrt14 kernel: [  176.074518] EXT4-fs error (device dm-0): ext4_find_extent:913: inode #44957706: comm kvm: pblk 234161639 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Oct 26 09:56:51 vrt14 kernel: [  176.074829] EXT4-fs error (device dm-0): ext4_find_extent:913: inode #44957706: comm kvm: pblk 234161639 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Oct 26 09:56:51 vrt14 kernel: [  176.074962] EXT4-fs error (device dm-0): ext4_find_extent:913: inode #44957706: comm kvm: pblk 234161639 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Oct 26 09:56:51 vrt14 kernel: [  176.087147] EXT4-fs error (device dm-0): ext4_find_extent:913: inode #44957706: comm kvm: pblk 234161639 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Oct 26 09:56:51 vrt14 kernel: [  176.087520] EXT4-fs error (device dm-0): ext4_find_extent:913: inode #44957706: comm kvm: pblk 234161639 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Oct 26 09:56:51 vrt14 kernel: [  176.103127] EXT4-fs error (device dm-0): ext4_find_extent:913: inode #44957706: comm kvm: pblk 234161639 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Oct 26 09:56:51 vrt14 kernel: [  176.103537] EXT4-fs error (device dm-0): ext4_find_extent:913: inode #44957706: comm kvm: pblk 234161639 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)
Oct 26 09:56:51 vrt14 kernel: [  176.107169] EXT4-fs error (device dm-0): ext4_find_extent:913: inode #44957706: comm kvm: pblk 234161639 bad header/extent: invalid magic - magic 0, entries 0, max 0(0), depth 0(0)

Relevante software en hardware die ik gebruik
HP DL380 Gen10 met RAID
HP Smart Array P408i-a SR Gen10 (BBU / alles ok-status)
Linux vrt14 5.0.21-5-pve #1 SMP PVE 5.0.21-10 (Wed, 13 Nov 2019 08:27:10 +0100) x86_64 GNU/Linux

Wat ik al gevonden of geprobeerd heb
fsck gedaan, vele errors laten repareren, niks opgelost, qemu-img check gedaan op de virtuele images, ook fouten, helaas starten ook virtuele servers niet meer en klagen ze (logischerwijs) ook over corrupties en/of root-disks die niet willen starten.

Corrupte VM's dus, je snapt mijn schrik & frustratie...

[Jouke74]

Heb je een geheel nieuwe swapfile gemaakt? Ja. Maar ook deze heet weer swapfile.

Ik vermoed dat je de al oudere /root/swapfile hebt overschreven met de tweede "swapon". Gegeven dat ie stevig in gebruik was zal daar dus ook een deel van je filesystem journalling in hebben gestaan, en heb je dus een groot probleem.

Oplossen wordt (hopelijk) de backup laden vrees ik...

[BoAC]

Als dat zo is, heeft hij een major kernelbug gevonden

[Keiichi]

Uit mkswap:

code:

To setup a swap file, it is necessary to create that file before initializing it with mkswap, e.g. using a command

like

# dd if=/dev/zero of=swapfile bs=1024 count=65536
Note that a swap file must not contain any holes (so, using cp(1) to create the file is not acceptable).

fallocate doet:

code:

       fallocate is used to manipulate the allocated disk space for a
       file, either to deallocate or preallocate it. For filesystems
       which support the fallocate system call, preallocation is done
       quickly by allocating blocks and marking them as uninitialized,
       requiring no IO to the data blocks. This is much faster than
       creating a file by filling it with zeroes.

Ik weet niet of het de oorzaak is, maar mkswap heeft wel echt een waarschuwing staan voor file-based swap files

[vmsw]

Controleer vooral, maar op basis van mijn commando's trek ik zelf conclusies:
- Na de fallocate heb ik een mkswap gedaan dus ik doe netjes wat Keiichi aangeeft toch (?)
- Ik zat in een andere map dan /root (namelijk /ssd) dus daarmee heb ik het bestand niet zelf overschreven maar gaat iets bijzonder vreemd in kernel toch?

Klopt dat, of moet ik begrijpen dat ik iets doms gedaan heb?

[Keiichi]

Ik weet niet of het nuttig gaat zijn, kun je informatie geven over: partitie layout, lvm structuur, evt crypto (ik zie dat er dm-[0-1] devices zijn, wellicht dat je luks encryptie hebt.

[deHakkelaar]

Ik vermoed dat net als @Keiichi al aangaf, het mis ging met fallocate welke specifiek genoemd wordt:

$ man swapon
[..]
       The  swap  file implementation in the kernel expects to be able to write to
       the file directly, without the assistance of the  filesystem.   This  is  a
       problem  on preallocated files (e.g.  fallocate(1)) on filesystems like XFS
       or ext4, and on copy-on-write filesystems like btrfs.

       It is recommended to use dd(1) and /dev/zero to  avoid  holes  on  XFS  and
       ext4.

[MartinMeijerink]

Moet een hardwareprobleem zijn.
Testje op een Debian Buster-servertje hier:

birdhill:/ # truncate -s8G /swapfile
birdhill:/ # mkswap /swapfile
birdhill:/ # chmod 600 /swapfile 
Setting up swapspace version 1, size = 8 GiB (8589930496 bytes)
no label, UUID=6cba4600-f684-4f1c-933d-72832e885f5b
birdhill:/ # swapon /swapfile
swapon: /swapfile: skipping - it appears to have holes.
birdhill:/ # ls -l /swapfile 
-rw------- 1 root root 8589934592 2021-10-27 19:39 /swapfile
birdhill:/ # du -sh swapfile 
4.0K	swapfile

Hier zie je nl. in regel 8 dat swapon het wel in de gaten heeft als het opgegeven bestand sparsed is.
Zelf doe ik het ook altijd met fallocate, nooit problemen mee gehad, nu even voor de test:

birdhill:/ # rm /swapfile
birdhill:/ # fallocate -l 8G /swapfile
birdhill:/ # mkswap /swapfile
birdhill:/ # chmod 600 /swapfile 
Setting up swapspace version 1, size = 8 GiB (8589930496 bytes)
no label, UUID=ccb6f1a0-b9f7-4c14-9a24-5b3bf940d4ed
birdhill:/ # swapon /swapfile
birdhill:/ # swapon
NAME      TYPE      SIZE USED PRIO
/dev/sda2 partition 1.9G   0B   -2
/swapfile file        8G   0B   -3
birdhill:/ # ls -l /swapfile 
-rw------- 1 root root 8589934592 2021-10-27 19:41 /swapfile
birdhill:/ # du -sh /swapfile 
8.1G	/swapfile

Ik denk dus echt een hardwareprobleem, ik heb in ieder geval nog nooit meegemaakt dat zoiets tot datacorruptie kan leiden.

[deHakkelaar]

code:

findmnt /ssd

???
Ik heb ervaren dat je met Btrfs speciale maatregelingen moet treffen voor swap files ivm CoW.
En de man page geeft ook fallocate specifiek aan als een probleem.
Maar goed HW kan ook.

[Thralas]

vmsw schreef op woensdag 27 oktober 2021 @ 12:01:
- Ik zat in een andere map dan /root (namelijk /ssd) dus daarmee heb ik het bestand niet zelf overschreven maar gaat iets bijzonder vreemd in kernel toch?

Klopt dat, of moet ik begrijpen dat ik iets doms gedaan heb?

Ik zie tot dusver ook niets doms, maar wat is dm-1 eigenlijk? En hoe verhoudt dat zich tot /ssd (ext4 op lvm?)

A warning about 5.12-rc1

But I want everybody to be aware of because _if_ it bites you, it
bites you hard, and you can end up with a filesystem that is
essentially overwritten by random swap data. This is what we in the
industry call "double ungood".

Die bug zit in een veel recentere kernel, maar iets vergelijkbaars lijkt wel aan de hand. Aan het feit dat je filesystem corrupt is valt af te leiden dat er swap terecht is gekomen op een plek waar het niet hoort.

Anders dan wat posts hierboven denk ik dat de waarschuwing tov. fallocate niet terecht is: dat maakt geen file met holes aan op ext4: vergelijk maar eens de output van filefrag -e van een fallocated file met een sparse file.

Er is wel opvallend veel swap pressure (aangenomen dat je direct na enablen swap hebt weergegeven), en swap files zijn niche (aldus Linus). Misschien is dat toch voldoende om tegen dit soort bugs aan te lopen.

Ik zou in ieder geval je kernel updaten (die is vrij oud, dus grote kans dat dat helpt) en geen swap files meer gebruiken.

[vmsw]

Eerlijkheidshalve heb ik vaker swapfiles gemaakt, maar weinig/nooit met fallocate, ik gebruikte altijd het dd if=/dev/zero commando. Omdat ik uit gemak via Google zocht wat dit commando was (create swap file), zag ik die fallocate als alternatief en dat klonk wel makkelijker. Nooit gedacht aan een eventueel verschil.
Kennelijk zijn swapfiles een slecht idee, dus wellicht moet ik hier beter rekening mee houden bij het opzetten van (fysieke) servers en hun schijf/partitie-indeling.

Even tussendoor, op basis van jullie reacties leid ik af dat we het er wel over eens zijn dat mijn handeling 'het probleem' is (of het nou bug is of niet) en ik de server (hardware e.d.) kan vertrouwen (?).
Server is nu uit productie namelijk, en hij is eigenlijk wel weer nodig.
Wellicht dat ik vooraf nog een of andere memory en/of disk check zal doen en de /ssd-disk (RAID10 met HP controller) opnieuw formatteer. Nu nog filesystem kiezen maar dat is een ander hoofdstuk

code:

root@vrt14:/dev# dmsetup ls
pve-data_tdata  (253:4)
pve-data_tmeta  (253:3)
pve-swap        (253:1)
pve-root        (253:2)
pve-data        (253:5)
3600508b1001cdf9244b3582b1fae00fe       (253:6)
vg--ssd-ssd     (253:0)

root@vrt14:/dev# lsblk
NAME                                MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                                   8:0    0 223.6G  0 disk
├─sda1                                8:1    0     1M  0 part
├─sda2                                8:2    0   256M  0 part  /boot/efi
├─sda3                                8:3    0  29.8G  0 part
│ ├─pve-swap                        253:1    0   3.6G  0 lvm   [SWAP]
│ ├─pve-root                        253:2    0   7.3G  0 lvm   /
│ ├─pve-data_tmeta                  253:3    0    16M  0 lvm
│ │ └─pve-data                      253:5    0  15.3G  0 lvm
│ └─pve-data_tdata                  253:4    0  15.3G  0 lvm
│   └─pve-data                      253:5    0  15.3G  0 lvm
└─sda4                                8:4    0 193.5G  0 part  /root2
sdb                                   8:16   0   1.8T  0 disk
├─vg--ssd-ssd                       253:0    0   1.8T  0 lvm   /ssd
└─3600508b1001cdf9244b3582b1fae00fe 253:6    0   1.8T  0 mpath

root@vrt14:/dev# lvs
  /dev/sdc: open failed: No medium found
  WARNING: Not using device /dev/mapper/3600508b1001cdf9244b3582b1fae00fe for PV 45OdTg-2dg1-hk2H-wqws-zDH3-LuwY-ocjj5r.
  WARNING: PV 45OdTg-2dg1-hk2H-wqws-zDH3-LuwY-ocjj5r prefers device /dev/sdb because device is used by LV.
  LV   VG     Attr       LSize  Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data pve    twi-a-tz-- 15.25g             0.00   10.57
  root pve    -wi-ao----  7.25g
  swap pve    -wi-ao----  3.62g
  ssd  vg-ssd -wi-ao---- <1.75t
root@vrt14:/dev# vgs
  /dev/sdc: open failed: No medium found
  WARNING: Not using device /dev/mapper/3600508b1001cdf9244b3582b1fae00fe for PV 45OdTg-2dg1-hk2H-wqws-zDH3-LuwY-ocjj5r.
  WARNING: PV 45OdTg-2dg1-hk2H-wqws-zDH3-LuwY-ocjj5r prefers device /dev/sdb because device is used by LV.
  VG     #PV #LV #SN Attr   VSize   VFree
  pve      1   3   0 wz--n- <29.75g <3.59g
  vg-ssd   1   1   0 wz--n-  <1.75t     0
root@vrt14:/dev# pvs
  /dev/sdc: open failed: No medium found
  WARNING: Not using device /dev/mapper/3600508b1001cdf9244b3582b1fae00fe for PV 45OdTg-2dg1-hk2H-wqws-zDH3-LuwY-ocjj5r.
  WARNING: PV 45OdTg-2dg1-hk2H-wqws-zDH3-LuwY-ocjj5r prefers device /dev/sdb because device is used by LV.
  PV         VG     Fmt  Attr PSize   PFree
  /dev/sda3  pve    lvm2 a--  <29.75g <3.59g
  /dev/sdb   vg-ssd lvm2 a--   <1.75t     0

root@vrt14:/dev# dmsetup info /dev/dm-0
Name:              vg--ssd-ssd
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        1
Event number:      0
Major, minor:      253, 0
Number of targets: 1
UUID: LVM-5Sp0P0c0gOtpe2ms7JXWi0ffHgcIOSA5JdH9Gn7W19RVOZYxqJn6hUIDkTe1BbCc

root@vrt14:/dev# dmsetup info /dev/dm-1
Name:              pve-swap
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        2
Event number:      0
Major, minor:      253, 1
Number of targets: 1
UUID: LVM-rEzt3YfO8a3lp5aocpQpCcBt1jor3rYJsPn5EfuzE2qlloHul6j6gkSTZhRPT1CV

root@vrt14:/dev# dmsetup info /dev/dm-2
Name:              pve-root
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        1
Event number:      0
Major, minor:      253, 2
Number of targets: 1
UUID: LVM-rEzt3YfO8a3lp5aocpQpCcBt1jor3rYJM6o5h0H2u37L4m9JjbXhl0QEtpF3Q42d

root@vrt14:~# findmnt
TARGET                                SOURCE     FSTYPE     OPTIONS
/                                     /dev/mapper/pve-root
│                                                ext4       rw,relatime,errors=remount-ro,stripe=64
├─/sys                                sysfs      sysfs      rw,nosuid,nodev,noexec,relatime
... (veel sys-dirs)
├─/proc                               proc       proc       rw,relatime
│ └─/proc/sys/fs/binfmt_misc          systemd-1  autofs     rw,relatime,fd=45,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=55441
├─/dev                                udev       devtmpfs   rw,nosuid,relatime,size=131870172k,nr_inodes=32967543,mode=755
│ ├─/dev/pts                          devpts     devpts     rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000
│ ├─/dev/shm                          tmpfs      tmpfs      rw,nosuid,nodev
│ ├─/dev/mqueue                       mqueue     mqueue     rw,relatime
│ └─/dev/hugepages                    hugetlbfs  hugetlbfs  rw,relatime,pagesize=2M
├─/run                                tmpfs      tmpfs      rw,nosuid,noexec,relatime,size=26379168k,mode=755
│ ├─/run/lock                         tmpfs      tmpfs      rw,nosuid,nodev,noexec,relatime,size=5120k
│ ├─/run/rpc_pipefs                   sunrpc     rpc_pipefs rw,relatime
│ └─/run/user/1000                    tmpfs      tmpfs      rw,nosuid,nodev,relatime,size=26379164k,mode=700,uid=1000,gid=1000
├─/ssd                                /dev/mapper/vg--ssd-ssd
│                                                ext4       rw,relatime,stripe=512
├─/root2                              /dev/sda4  ext4       rw,relatime,stripe=64
├─/boot/efi                           /dev/sda2  vfat       rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro
├─/var/lib/lxcfs                      lxcfs      fuse.lxcfs rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other
├─/etc/pve                            /dev/fuse  fuse       rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other
... (aantal nfs-shares)

Trouwens, weet niet of interessant/relevant, maar:

code:

root@vrt14:/ssd# filefrag /root2/swapfile
/root2/swapfile: 16 extents found
root@vrt14:/ssd# filefrag /ssd/swapfile
/ssd/swapfile: 23313 extents found

De /root2/swapfile is vermoedelijk eentje die aangemaakt is met dd.
De /ssd/swapfile is degene waarop alles mis ging, gemaakt met fallocate.

[ Voor 6% gewijzigd door vmsw op 28-10-2021 14:23 ]

[Keiichi]

Als ik het zo zie mag je wat uitleg geven over je device /dev/sdc die er niet meer is schijnbaar. En dat die weer een voorkeur naar /dev/sdb waar nu schijbnaar de corruptie ook op zit.

Ik kan er zelf even geen beeld krijgen waarom er onder sdb een mpath iets staat. Wellicht dat je meer kan vertellen over de schijven, raidconfiguratie die je gebruikt.


Met een snelle test in een vm met fallocate en swapfile ben ik zelf nergens tegenaan gelopen. Hoewel swap-file niches zijn hoeft het nog geen probleem te zijn, het kan wel een probleem worden als je blockdevice corrupt, waardoor swap corrupt is, waardoor je geheugen corrupt is. Maar dat kan zich net zo goed uiten in een willekeurige crash en niet zo specifiek op het fs, wat andere vermoeden met hardware zou denk wel het meest voor de handliggend zijn nog (configuratie van de raidcontroller misschie nook nog)

[BoAC]

Wat ik mij afvraag: waarom zo enorm veel swap?
Dat komt de performance van de VM's niet ten goede lijkt mij. Beter kun je Ram uitbreiden. Swap is alleen voor het noodgeval als je Ram volloopt lijkt mij.

[vmsw]

@BoAC
Swap: server heeft 256GB geheugen. Ik zie vaak dat de swap al gebruikt wordt, zelfs al lijkt er nog gewoon ruim geheugen beschikbaar, dus nam aan dat het OS dit een beter idee vond om bij voorbaat alvast apart te zetten.

Als ik bijv. inlog op een andere server binnen dit cluster, zie ik dat er 378GB geheugen is, daarvan is slechts 229GB gebruikt, rest file cache is (geel in htop) en daar bovendien 12GB swap in gebruik is. Mijn aanname is dat het OShet overbodige geheugen opvult met 'cache' (dus er geen geheugenlimiet bereikt), en het feit dat swap gebruikt wordt dus meer een keuze van het OS is.Of vind je dat ik de swappiness moet aanpassen en/of gaat hier al iets mis?

@Keiichi
Ik vind het bijzonder onhandig, maar weet niet zo goed hoe het zit met die /dev/sdc. Wel weet ik dat er in verleden vermoedelijk een iscsi (netwerk)target geconfigureerd was op deze server, waarbij mogelijk/allicht mpath gebruikt is. Ik vermoed dus oud zeer.

[BoAC]

Wat meer info over swapfiles: https://wiki.gentoo.org/wiki/Swap en uiteraard google
Ik heb idd ook gevonden dat swapfiles op btrfs wat meer aandacht vereist: https://wiki.archlinux.org/title/Btrfs#Swap_file. Ik weet alleen niet of op jouw omgeving btrfs wordt gebruikt

Swap gebruiken voor caching van filesysteem heeft totaal geen zin, tenzij swap op snellere storage staat dan het originele filesysteem wat gecached wordt.

Heb je misschien meer memory gealloceerd voor VM's dan beschikbaar is op je host?

Ik vraag mij af of het verstandig is om veel swap op een machine te hebben die veel (actieve?) hosts heeft.
Een rekensom is dan handig: 'host memory usage' + sum(guest memory) + iets slack < total Ram.
Een 8 GB swap partitie lijkt mij dan voldoende.
De swap usage heb je het liefst op 0 tot een gig. Wanneer het erboven gaat denk ik dat je gewoon teveel vraagt van je host en zal dit je performance gaat kosten. Ik zie swap dus meer als veiligheid om te voorkomen dat de oom-killer voortijdig processen zal killen.

Ik ben geen VM expert, dit bovenstaande zeg ik gewoon met gezond verstand en ervaring met VM's hier thuis.
Een beetje onderzoek levert wel op dat geheugen van hosts gecombineerd (geshared) kan worden zoals bijv. bij gelijk gebruik van kernels, maar dit zal naar mijn idee niet veel meer opleveren.

[vmsw]

@BoAC Op de server van mijn vorige voorbeeld wordt 227GB aan geheugen toegewezen aan de VM's. Het verbruik (groen in htop / 'used' in free -hm) is 229GB.

Het blijft dus dat er een gat zit van 149GB die kennelijk 'vanzelf' als 'cache' gebruikt wordt. En nog 12,5GB als swap.

code:

root@VRT16:/home/username# free -hm
              total        used        free      shared  buff/cache   available
Mem:          377Gi       228Gi        13Gi       359Mi       135Gi       146Gi
Swap:          51Gi        12Gi        39Gi

root@VRT16:/home/username# cat /proc/sys/vm/swappiness
60

Mogelijkerwijs inderdaad wel handig om swappiness naar 10 te zetten. Want inderdaad, hij lijkt dit onnodig vaak te doen.

[ Voor 14% gewijzigd door vmsw op 29-10-2021 09:43 ]

[BoAC]

En nog een tip: gebruik liever geen swap-files maar gewoon devices (storage)

[deHakkelaar]

vmsw schreef op vrijdag 29 oktober 2021 @ 09:38:
[..]
Het verbruik (groen in htop / 'used' in free -hm) is 229GB.
[..]

FYI, als je host lang genoeg draait, wordt zelfs het gehele vrije geheugen gevuld met cache en is dus ook "used":
https://www.linuxatemyram.com/

[vmsw]

Ja, zo'n vermoeden had ik al. Gek genoeg wordt hier gesuggereerd dat er niet geswapt wordt op basis van deze cache, wat uiteraard logisch/goed is. Tegelijkertijd zie ik wel swap, terwijl ik zeker weet dat ik nooit in buurt van 100% gekomen ben.

Ik gok dus dat mijn swappiness van 60 (default?) te enthousiast is, en oplossing zit in swappiness naar 10 zetten.

En voor swap klinkt inderdaad handig(er) om grotere partities te maken en/of ongepartitioneerde ruimte vrij te houden voor latere bestemming. Vaak wees ik alle ruimte toe aan primaire partitie, waardoor swapfiles de makkelijkste/meest logische oplossing leken. Kennelijk met een nadeel/risico.

[BoAC]

Ow wacht, je past je swappiness aan? Als je die aanpast zal idd de kernel sneller besluiten om appicaties die 'slapen' sneller in de swap te zetten. Volgens mij wil je dat echt niet voor een VM omgeving: https://linuxhint.com/understanding_vm_swappiness/.

Stel je VM guest is op een moment rustig. Ruimte in je Ram wordt dan vrij gemaakt voor disk cache door die betreffende VM naar Swap te zetten. Cache komt dan vrij voor disk cache voor de VM's die wel druk zijn.

Dit heeft in ieder geval 2 nadelen:

1. Wordt de 'slapende' VM weer actief, zal dit heel traag gaan omdat hij van Swap gehaald moet worden.
2. In geval van een crash (wat de reden ook mag zijn) van een andere VM proces (vanuit host gezien) loop je een hoger risico op corruptie (denk ik)

Naar mijn idee moet je swappiness (als je dat al wil) op je guest regelen en nooit op je Host

[vmsw]

@BoAC ik heb de swappinness nooit aangepast, maar de default lijkt op 60 te staan, en kennelijk levert dit swap-gebruik op (ondanks er nog meer dan genoeg ruimte lijkt te zijn om zónder swap te werken)

MIjn opzet/bedoeling is dus om op host-niveau de swappiness op bijv. 10 i.p.v. default 60 te zetten. Dit omdat er kennelijk veel geswapt wordt anders.
Op VM-niveau heb ik niet over nagedacht, maar in theorie kan dit ook natuurlijk inderdaad. Maar vaak is dit beter behapbaar omdat het om kleinere hoeveelheid geheugen gaat. En ik moet zeggen hier minder vaak veel swap te zien zonder duidelijke reden.

[ Voor 20% gewijzigd door vmsw op 29-10-2021 14:38 ]

[nvaert1986]

vmsw schreef op donderdag 28 oktober 2021 @ 16:13:
@BoAC
Swap: server heeft 256GB geheugen. Ik zie vaak dat de swap al gebruikt wordt, zelfs al lijkt er nog gewoon ruim geheugen beschikbaar, dus nam aan dat het OS dit een beter idee vond om bij voorbaat alvast apart te zetten.

Als ik bijv. inlog op een andere server binnen dit cluster, zie ik dat er 378GB geheugen is, daarvan is slechts 229GB gebruikt, rest file cache is (geel in htop) en daar bovendien 12GB swap in gebruik is. Mijn aanname is dat het OShet overbodige geheugen opvult met 'cache' (dus er geen geheugenlimiet bereikt), en het feit dat swap gebruikt wordt dus meer een keuze van het OS is.Of vind je dat ik de swappiness moet aanpassen en/of gaat hier al iets mis?

@Keiichi
Ik vind het bijzonder onhandig, maar weet niet zo goed hoe het zit met die /dev/sdc. Wel weet ik dat er in verleden vermoedelijk een iscsi (netwerk)target geconfigureerd was op deze server, waarbij mogelijk/allicht mpath gebruikt is. Ik vermoed dus oud zeer.

Als je gegarandeerd geheugen hebt en bijna geen swap nodig hebt, dan kun je de swapiness aanpassen.

Dat doe je d.m.v. sudo sysctl vm.swappiness=10
De waarde 10 geeft aan dat swap wordt ingeschakeld op het moment dat 10% van het geheugen nog beschikbaar is en dus 90% in gebruik is. Dan wordt swap in principe bijna nooit gebruikt indien niet nodig.
Deze wijziging wordt direct doorgevoerd, maar gaat verloren bij een reboot.

Om dit permanent te maken is het advies dit tevens te wijzigen in /etc/sysctl.conf zodat de wijziging permanent is.