Ich verzweifle - binnen zwei Wochen erneut "Thin pool pve/data needs check has read-only metadata." muss ich erneut aufsetzen?

[Iacov]

hallo

ich weiß nicht mehr weiter
ich habe zwei PVE geräte...das eine läuft seit ewigkeiten mehr oder minder rock solid, beim zweiten habe ich vor zwei wochen das erste mal den fehler gehabt den ich nun wieder habe, habe mich aber damals dafür entschieden das system neu aufzusetzen weil mir tabula-rasa schneller vorkam als auf ewige fehlersuche zu gehen

nun ist der fehler aber wieder da, das heißt ich muss den root-cause ermitteln, kenne mich dafür aber in linux bzw mit proxmox zu wenig aus

Ich weiß nicht wo ich beginnen soll das Problem zu beschreiben oder meine Theorie wann und wie es auftreten könnte - bitte sagt mir welche infos/logs ich hier posten kann, damit ihr vll einen rückschluss ziehen könnt was passiert

konkret geht nichts mehr (zb VM erstellen) weil ich u.a. die fehlermeldung "Thin pool pve/data needs check has read-only metadata." bekomme

beim versuch eine VM wiederherzustellen erhalte ich:

 Cannot send messages to thin pool pve-data-tpool (252:4) with read only metadata which needs check first.
  Failed to suspend pve/data with queued messages.
unable to cleanup 'local-lvm:vm-210-disk-0' - lvremove 'pve/vm-210-disk-0' error:   Failed to update pool pve/data.
no lock found trying to remove 'create'  lock
error before or during data restore, some or all disks were not completely restored. VM 210 state is NOT cleaned up

ich glaube, dass das problem unmittelbar heute nach meinem wöchentlichen nas-backup aufgetreten ist (jeden freitag morgen werden die VMs von PVE2 auf mein nas gesichert - es ist kein PBS im einsatz)
konkret habe ich 2 VMs auf PVE2 laufen
- jellyfin (die VM hat 150gb zur verfügung, nutzt aber nur knapp 30)
- pihole (die vm hat 10gb zur vergügung, nutzt aber nur knapp 1gb)

ich weiß leider weder was das problem konkret jedes mal verursacht noch wie ich das problem lösen kann - außer das ich das komplette system neu aufsetze, was ja auch nicht sinn der sache sein kann

habt ihr eine idee?
wie kann ich konkret diagnostizieren was mit meinem system nicht stimmt?
sry, falls die beschrteibung im ersten moment chaotisch wirkt...bin gerade am verzweifeln womöglich wieder alles neu aufsetzen zu müssen


edit: es dürfte wahrscheinlich nur local-lvm betreffen. denn testweise konnte ich erfolgreich ein neues iso image auf local hochladen
edit 2: lvs -a spuckt folgendes aus:

  LV                       VG  Attr       LSize   Pool Origin        Data%  Meta%  Move Log Cpy%Sync Convert
  data                     pve twi-cotzM- 337.86g                    18.73  1.19
  [data_tdata]             pve Twi-ao---- 337.86g
  [data_tmeta]             pve ewi-ao----  <3.45g
  [lvol0_pmspare]          pve ewi-------  <3.45g
  root                     pve -wi-ao----  96.00g
  snap_vm-201-disk-0_snap1 pve Vri---tz-k 150.00g data vm-201-disk-0
  swap                     pve -wi-ao----   8.00g
  vm-201-disk-0            pve Vwi-aotz-- 150.00g data               31.71

edit 3: lvdisplay pve/data spuckt folgendes aus:

  --- Logical volume ---
  LV Name                data
  VG Name                pve
  LV UUID                nr5Iuq-TmA2-W614-kLTr-wULq-mhxz-3rWTub
  LV Write Access        read/write (activated read only)
  LV Creation host, time proxmox, 2024-06-08 16:33:14 +0200
  LV Pool metadata       data_tmeta
  LV Pool data           data_tdata
  LV Status              available
  # open                 0
  LV Size                337.86 GiB
  Allocated pool data    18.73%
  Allocated metadata     1.19%
  Current LE             86493
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:5

das log (gesendet via gotify) vom heutigen backup task:

Details
=======
VMID    Name           Status    Time     Size           Filename                                                                  
201     SV-Jellyfin    ok        6min     28 GiB         /mnt/pve/nas/dump/vzdump-qemu-201-2024_06_21-04_30_04.vma.zst
210     PiHole2        ok        26s      831.515 MiB    /mnt/pve/nas/dump/vzdump-qemu-210-2024_06_21-04_36_04.vma.zst


Total running time: 6min 26s
Total size: 28.812 GiB

Logs
====
vzdump --fleecing 0 --storage nas --compress zstd --mode stop --node pve2 --prune-backups 'keep-weekly=3' --all 1 --notes-template '{{guestname}}' --notification-mode notification-system --quiet 1


201: 2024-06-21 04:30:04 INFO: Starting Backup of VM 201 (qemu)
201: 2024-06-21 04:30:04 INFO: status = running
201: 2024-06-21 04:30:04 INFO: backup mode: stop
201: 2024-06-21 04:30:04 INFO: ionice priority: 7
201: 2024-06-21 04:30:04 INFO: VM Name: SV-Jellyfin
201: 2024-06-21 04:30:04 INFO: include disk 'scsi0' 'local-lvm:vm-201-disk-0' 150G
201: 2024-06-21 04:30:04 INFO: stopping virtual guest
201: 2024-06-21 04:30:30 INFO: snapshots found (not included into backup)
201: 2024-06-21 04:30:30 INFO: creating vzdump archive '/mnt/pve/nas/dump/vzdump-qemu-201-2024_06_21-04_30_04.vma.zst'
201: 2024-06-21 04:30:30 INFO: starting kvm to execute backup task
201: 2024-06-21 04:30:33 INFO: started backup task '52ee4736-0009-4011-a95f-b943e9e56848'
201: 2024-06-21 04:30:33 INFO: resuming VM again after 29 seconds
201: 2024-06-21 04:30:36 INFO:   1% (2.3 GiB of 150.0 GiB) in 3s, read: 801.1 MiB/s, write: 259.8 MiB/s
201: 2024-06-21 04:30:40 INFO:   2% (3.1 GiB of 150.0 GiB) in 7s, read: 184.9 MiB/s, write: 179.5 MiB/s
201: 2024-06-21 04:30:48 INFO:   3% (4.7 GiB of 150.0 GiB) in 15s, read: 208.9 MiB/s, write: 190.0 MiB/s
201: 2024-06-21 04:30:54 INFO:   4% (6.3 GiB of 150.0 GiB) in 21s, read: 268.2 MiB/s, write: 118.2 MiB/s
201: 2024-06-21 04:30:57 INFO:   6% (10.0 GiB of 150.0 GiB) in 24s, read: 1.2 GiB/s, write: 131.0 MiB/s
201: 2024-06-21 04:31:00 INFO:   7% (10.6 GiB of 150.0 GiB) in 27s, read: 209.0 MiB/s, write: 169.8 MiB/s
201: 2024-06-21 04:31:09 INFO:   8% (12.1 GiB of 150.0 GiB) in 36s, read: 164.7 MiB/s, write: 158.6 MiB/s
201: 2024-06-21 04:31:18 INFO:   9% (13.6 GiB of 150.0 GiB) in 45s, read: 177.6 MiB/s, write: 163.8 MiB/s
201: 2024-06-21 04:31:26 INFO:  10% (15.0 GiB of 150.0 GiB) in 53s, read: 175.8 MiB/s, write: 165.9 MiB/s
201: 2024-06-21 04:31:38 INFO:  11% (16.6 GiB of 150.0 GiB) in 1m 5s, read: 133.2 MiB/s, write: 125.8 MiB/s
201: 2024-06-21 04:31:48 INFO:  12% (18.0 GiB of 150.0 GiB) in 1m 15s, read: 151.2 MiB/s, write: 148.1 MiB/s
201: 2024-06-21 04:31:58 INFO:  13% (19.6 GiB of 150.0 GiB) in 1m 25s, read: 154.8 MiB/s, write: 143.0 MiB/s
201: 2024-06-21 04:32:11 INFO:  14% (21.1 GiB of 150.0 GiB) in 1m 38s, read: 123.8 MiB/s, write: 121.8 MiB/s
201: 2024-06-21 04:32:18 INFO:  15% (22.5 GiB of 150.0 GiB) in 1m 45s, read: 204.6 MiB/s, write: 194.5 MiB/s
201: 2024-06-21 04:32:26 INFO:  16% (24.1 GiB of 150.0 GiB) in 1m 53s, read: 197.1 MiB/s, write: 176.9 MiB/s
201: 2024-06-21 04:32:35 INFO:  17% (25.5 GiB of 150.0 GiB) in 2m 2s, read: 166.3 MiB/s, write: 160.8 MiB/s
201: 2024-06-21 04:32:44 INFO:  18% (27.0 GiB of 150.0 GiB) in 2m 11s, read: 170.4 MiB/s, write: 157.6 MiB/s
201: 2024-06-21 04:32:53 INFO:  19% (28.6 GiB of 150.0 GiB) in 2m 20s, read: 184.5 MiB/s, write: 181.9 MiB/s
201: 2024-06-21 04:33:02 INFO:  20% (30.1 GiB of 150.0 GiB) in 2m 29s, read: 170.4 MiB/s, write: 141.2 MiB/s
201: 2024-06-21 04:33:13 INFO:  21% (31.7 GiB of 150.0 GiB) in 2m 40s, read: 142.0 MiB/s, write: 115.1 MiB/s
201: 2024-06-21 04:33:22 INFO:  22% (33.0 GiB of 150.0 GiB) in 2m 49s, read: 152.7 MiB/s, write: 129.6 MiB/s
201: 2024-06-21 04:33:31 INFO:  23% (34.6 GiB of 150.0 GiB) in 2m 58s, read: 176.0 MiB/s, write: 147.3 MiB/s
201: 2024-06-21 04:33:41 INFO:  24% (36.1 GiB of 150.0 GiB) in 3m 8s, read: 157.7 MiB/s, write: 148.2 MiB/s
201: 2024-06-21 04:33:49 INFO:  25% (37.6 GiB of 150.0 GiB) in 3m 16s, read: 189.4 MiB/s, write: 182.0 MiB/s
201: 2024-06-21 04:33:54 INFO:  26% (39.1 GiB of 150.0 GiB) in 3m 21s, read: 303.8 MiB/s, write: 161.8 MiB/s
201: 2024-06-21 04:33:57 INFO:  27% (40.9 GiB of 150.0 GiB) in 3m 24s, read: 641.6 MiB/s, write: 186.7 MiB/s
201: 2024-06-21 04:34:02 INFO:  28% (42.8 GiB of 150.0 GiB) in 3m 29s, read: 376.3 MiB/s, write: 157.0 MiB/s
201: 2024-06-21 04:34:07 INFO:  29% (44.7 GiB of 150.0 GiB) in 3m 34s, read: 396.6 MiB/s, write: 164.2 MiB/s
201: 2024-06-21 04:34:10 INFO:  30% (45.2 GiB of 150.0 GiB) in 3m 37s, read: 178.8 MiB/s, write: 163.2 MiB/s
201: 2024-06-21 04:34:18 INFO:  31% (46.6 GiB of 150.0 GiB) in 3m 45s, read: 172.2 MiB/s, write: 170.8 MiB/s
201: 2024-06-21 04:34:26 INFO:  32% (48.2 GiB of 150.0 GiB) in 3m 53s, read: 205.7 MiB/s, write: 196.8 MiB/s
201: 2024-06-21 04:34:34 INFO:  33% (49.6 GiB of 150.0 GiB) in 4m 1s, read: 182.2 MiB/s, write: 160.9 MiB/s
201: 2024-06-21 04:34:43 INFO:  35% (53.6 GiB of 150.0 GiB) in 4m 10s, read: 453.5 MiB/s, write: 154.1 MiB/s
201: 2024-06-21 04:34:46 INFO:  44% (66.3 GiB of 150.0 GiB) in 4m 13s, read: 4.2 GiB/s, write: 33.4 MiB/s
201: 2024-06-21 04:34:49 INFO:  48% (72.4 GiB of 150.0 GiB) in 4m 16s, read: 2.0 GiB/s, write: 116.7 MiB/s
201: 2024-06-21 04:34:56 INFO:  49% (73.6 GiB of 150.0 GiB) in 4m 23s, read: 174.5 MiB/s, write: 170.7 MiB/s
201: 2024-06-21 04:35:06 INFO:  50% (75.0 GiB of 150.0 GiB) in 4m 33s, read: 146.4 MiB/s, write: 142.1 MiB/s
201: 2024-06-21 04:35:14 INFO:  51% (76.6 GiB of 150.0 GiB) in 4m 41s, read: 206.2 MiB/s, write: 192.9 MiB/s
201: 2024-06-21 04:35:23 INFO:  52% (78.2 GiB of 150.0 GiB) in 4m 50s, read: 173.2 MiB/s, write: 162.8 MiB/s
201: 2024-06-21 04:35:32 INFO:  53% (79.6 GiB of 150.0 GiB) in 4m 59s, read: 159.1 MiB/s, write: 155.7 MiB/s
201: 2024-06-21 04:35:41 INFO:  54% (82.1 GiB of 150.0 GiB) in 5m 8s, read: 295.0 MiB/s, write: 149.9 MiB/s
201: 2024-06-21 04:35:44 INFO:  64% (96.8 GiB of 150.0 GiB) in 5m 11s, read: 4.9 GiB/s, write: 36.0 KiB/s
201: 2024-06-21 04:35:47 INFO:  73% (109.5 GiB of 150.0 GiB) in 5m 14s, read: 4.2 GiB/s, write: 12.0 KiB/s
201: 2024-06-21 04:35:50 INFO:  81% (122.7 GiB of 150.0 GiB) in 5m 17s, read: 4.4 GiB/s, write: 9.3 KiB/s
201: 2024-06-21 04:35:53 INFO:  89% (134.2 GiB of 150.0 GiB) in 5m 20s, read: 3.8 GiB/s, write: 8.0 KiB/s
201: 2024-06-21 04:35:56 INFO:  95% (143.2 GiB of 150.0 GiB) in 5m 23s, read: 3.0 GiB/s, write: 5.3 KiB/s
201: 2024-06-21 04:35:59 INFO: 100% (150.0 GiB of 150.0 GiB) in 5m 26s, read: 2.3 GiB/s, write: 8.0 KiB/s
201: 2024-06-21 04:35:59 INFO: backup is sparse: 103.11 GiB (68%) total zero data
201: 2024-06-21 04:35:59 INFO: transferred 150.00 GiB in 326 seconds (471.2 MiB/s)
201: 2024-06-21 04:35:59 INFO: archive file size: 28.00GB
201: 2024-06-21 04:35:59 INFO: adding notes to backup
201: 2024-06-21 04:35:59 INFO: prune older backups with retention: keep-weekly=3
201: 2024-06-21 04:35:59 INFO: removing backup 'nas:backup/vzdump-qemu-201-2024_05_31-04_30_00.vma.zst'
201: 2024-06-21 04:36:04 INFO: pruned 1 backup(s) not covered by keep-retention policy
201: 2024-06-21 04:36:04 INFO: Finished Backup of VM 201 (00:06:00)

210: 2024-06-21 04:36:04 INFO: Starting Backup of VM 210 (qemu)
210: 2024-06-21 04:36:04 INFO: status = running
210: 2024-06-21 04:36:04 INFO: backup mode: stop
210: 2024-06-21 04:36:04 INFO: ionice priority: 7
210: 2024-06-21 04:36:04 INFO: VM Name: PiHole2
210: 2024-06-21 04:36:04 INFO: include disk 'scsi0' 'local-lvm:vm-210-disk-0' 10G
210: 2024-06-21 04:36:04 INFO: stopping virtual guest
210: 2024-06-21 04:36:07 INFO: snapshots found (not included into backup)
210: 2024-06-21 04:36:07 INFO: creating vzdump archive '/mnt/pve/nas/dump/vzdump-qemu-210-2024_06_21-04_36_04.vma.zst'
210: 2024-06-21 04:36:07 INFO: starting kvm to execute backup task
210: 2024-06-21 04:36:08 INFO: started backup task 'b52a3abc-9563-4c38-8b04-9b87e5fc0c45'
210: 2024-06-21 04:36:08 INFO: resuming VM again after 4 seconds
210: 2024-06-21 04:36:11 INFO:   8% (884.5 MiB of 10.0 GiB) in 3s, read: 294.8 MiB/s, write: 213.7 MiB/s
210: 2024-06-21 04:36:14 INFO:  16% (1.6 GiB of 10.0 GiB) in 6s, read: 268.2 MiB/s, write: 168.3 MiB/s
210: 2024-06-21 04:36:17 INFO:  21% (2.1 GiB of 10.0 GiB) in 9s, read: 170.4 MiB/s, write: 128.5 MiB/s
210: 2024-06-21 04:36:20 INFO:  35% (3.5 GiB of 10.0 GiB) in 12s, read: 472.5 MiB/s, write: 151.0 MiB/s
210: 2024-06-21 04:36:23 INFO:  62% (6.2 GiB of 10.0 GiB) in 15s, read: 913.5 MiB/s, write: 85.3 MiB/s
210: 2024-06-21 04:36:26 INFO: 100% (10.0 GiB of 10.0 GiB) in 18s, read: 1.3 GiB/s, write: 63.4 MiB/s
210: 2024-06-21 04:36:26 INFO: backup is sparse: 7.63 GiB (76%) total zero data
210: 2024-06-21 04:36:26 INFO: transferred 10.00 GiB in 18 seconds (568.9 MiB/s)
210: 2024-06-21 04:36:30 INFO: archive file size: 831MB
210: 2024-06-21 04:36:30 INFO: adding notes to backup
210: 2024-06-21 04:36:30 INFO: prune older backups with retention: keep-weekly=3
210: 2024-06-21 04:36:30 INFO: pruned 0 backup(s)
210: 2024-06-21 04:36:30 INFO: Finished Backup of VM 210 (00:00:26)

 

[Iacov]

ich bin noch am testen
aber um den read only status zu beheben habe ich lvm-thin genuked und neu erstellt
das habe ich vorher nie gemacht
ist dieser weg korrekt?
- lvm-thin in GUI löschen oder lvremove /dev/pve/data
- lvcreate -L 100g -n data pve (100g durch die passende größe ergänzen)
- lvconvert --type thin-pool pve/data

wenn die größe für metadata zu klein ist, vergrößern mit
- lvextend -poolmetadatasize +3g pve/data (3g durch die passende größe ergänzen)

das ganze hat zwar jetzt den read only status "behoben" ohne dass ich das ganze teil neu aufsetzen musste...aber es erklärt immer noch nicht die ursache des problems oder was es auslöst

ich habe wo gelesen, dass es passieren könnte wenn die verbindung zum netzlaufwerk abreißt - aber an sich sollte die stabil sein (gleiches vlan und lan verbindung) - PVE1 hat seinen backup job eine halbe stunde vorher und der läuft auch ohne probleme durch

edit: ich konnte zwar nun eine VM testweise installieren
doch nach einem update und neustart des PVE2 zeigt lvdisplay pve/data erneut read only status an

ich verzweifle - ich finde den verursachenden fehler/faktor nicht

 

[ThoSo]

Mann, mir ist gerade ein Bit vom Byte vom Controller über den DMA auf den PCI Bus gefallen, und hat dem Adaptec die Batterie mit einer Kernel Panic leergesaugt....
Hilft Dir das weiter?
Glaube nicht ....
Wäre ja schön, wenn man mal weiss was für ein System da mit Platten und Controller unterwegs ist - evtl. vielleicht noch ein Check des Logs.
Mal gesucht ob das schon mal jemand hatte.... bin dabei auf das gestossen:
https://forum.proxmox.com/threads/fehler-pve-data-needs-check-has-read-only-metadata.125353/
Try it!

 

[Iacov]

Mann, mir ist gerade ein Bit vom Byte vom Controller über den DMA auf den PCI Bus gefallen, und hat dem Adaptec die Batterie mit einer Kernel Panic leergesaugt....
Hilft Dir das weiter?
Glaube nicht ....
Wäre ja schön, wenn man mal weiss was für ein System da mit Platten und Controller unterwegs ist - evtl. vielleicht noch ein Check des Logs.
Mal gesucht ob das schon mal jemand hatte.... bin dabei auf das gestossen:
https://forum.proxmox.com/threads/fehler-pve-data-needs-check-has-read-only-metadata.125353/
Try it!

hab ich schon - aber zum einen trifft der thread nicht genau mein problem, zum anderen ist die conclusio das system neu aufzusetzen...das habe ich schon vor ein paar wochen probiert, als ich den thread das erste mal gefunden habe

habe auch andere threads zu ähnlichen themen gefunden, aber meist entweder ohne antworten oder ohne ergebnis

setup bei mir:
minisforum un100l
nvme (für local und local-lvm): wd red sn700
sata ssd (für lokale backups): wd red SA500

welchen log meinst du genau? den system-log unter node/system?
schwierig etwas eindeutiges zu finden
unter "read-only" findet sich nichts

unter "error" finden sich meldungen wie
pve2 kernel: EDAC igen6 MC0: HANDLING IBECC MEMORY ERROR
pve2 kernel: platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
pve2 kernel: iwlwifi 0000:00:14.3: Direct firmware load for iwlwifi-so-a0-jf-b0-86.ucode failed with error -2
pve2 kernel: iwlwifi 0000:00:14.3: 0x20000000 | FSEQ_ERROR_CODE

nichts davon würde ich ad hoc als verursacher zuordnen

 

[ThoSo]

Ein Türstopper PC - da hast ja mehr in die SSDs als in die Kiste investiert.
Wie ist den der SSD Controller im BIOS Konfiguriert - RAID oder AHCI?
Proxmox 8.?, Kernel 6.5 / 6.8?

210: 2024-06-21 04:36:07 INFO: creating vzdump archive '/mnt/pve/nas/dump/vzdump-qemu-210-2024_06_21-04_36_04.vma.zst'

Das geht noch nicht auf dein NAS, wie du oben geschrieben hast.

welchen log meinst du genau? den system-log unter node/system?
schwierig etwas eindeutiges zu finden
unter "read-only" findet sich nichts

Zu dem Zeitpunkt muss ja etwas passiert sein "ERROR" .... und das mal in den Logs suchen.


Mein Vorschlag für den TürstopperPC wäre, das Proxmox OS von den VMs trennen.
Das OS auf die NVME SSD - Installation default!
Dann die SATA-SSD für die VMs mit ext4 formatieren und darauf für den Datenstore ein VERZEICHNIS erstellen (kein LVM!).
Das mal laufen lassen und sehen ob' hält
Backup's aufs NAS oder auf die Proxmox Datenstores.
Und den On-Board Controller nicht im RAID laufen lassen.

 

[Iacov]

hey

nein, raid ist da nix - einfach plain die nvme für die pve installation und die sata ssd für die backups
proxmox 8.2.2 (bzw seit gestern updaten 8.2.4)
kernel 6.8.x

bzgl error in den logs - nein, ich habe leider keinen error um den gestrigen tag rum gefunden, den ich nicht oben erwähnt hätte
ich werde jedenfalls jetzt öfter/engmaschiger kontrollieren damit ich den tag, an dem es (sollte es) wieder auftritt, genauer dokumentieren kann
dann sollte ich auch eindeutiger sagen können ob sich zum zeitpunkt herum eindeutige meldungen finden oder nicht

warum empfiehlst du ext4? hab bei der letzten installation auf xfs gewechselt, weil ich letztens gelesen habe, dass xfs etwas resilienter ist - daher interessiert mich erfahrung und real world application

mir ist noch eine theorie eingefallen - bitte da um deine einschätzung
mein pve/data hat grob 330gb zur verfügung, meine jellyfin VM hat ja 150gb als disk, nutzt aber effektiv nur 30gb
auch wenn die 150 nur virtuell sind, so würde ich aus dem backup log schließen, dass PVE es trotzdem wie die nominellen 150gb behandelt.
könnte es also sein, dass die VM + Snapshot + der VZ dump fürs backup dafür sorgt, dass PVE kurzfristig denkt, dass die platte voll ist und daher auf read only switched? frage ist nur, kann ich das "sanfter" beheben als pve/data zu löschen?

und eine weitere frage ist mir noch untergekommen:
lvdisplay zeigt pve/data auf pve2 aktuell ja wieder mit "activated read only" an - obwohl alles norma zu funktionieren scheint
ich habe lvdisplay dann auch auf meinem pve1 gerät ausgeführt (gleiche platten-typen, aber anderer minisforum pc/hardware) und dort wird pve/data ebenfalls mit "activated read only" angezeigt, obwohl ich dort keinerlei probleme habe/hatte
wie ist das zu interpretieren?

edit: und kein hw shaming jeder fängt wo an und arbeitet mit dem platz und den mitteln die man zur verfügung hat

 

[floh8]

Mach doch mal ein memtest und checke die smartwerte der nvme

 

[ThoSo]

Ext4 ist ein altbewährtes und stabiles Linux Dateisystem und flach und KISS. Kannst auch XFS nutzen.
Trotzdem würde ich die VMs mal in einem Datenstore "VERZEICHNIS" laufen lassen - ohne den LVM Overhead.

Die Sicherungsdatei deiner VM sollte nur so groß sein, wie aktuelle auch seitens der VM genutzt wird. Also 30GB. Das kannst du ja unter Backups sehen. Wenn die Platte voll wäre, würde die Sicherung mit einem Fehler abbrechen, da kein Speicher verfügbar wäre.

Bei LVM wird (wenn ich das richtig im Kopf habe) zunächst die Platten R/O angesteuert und dann erst auf R/W umgestellt - kann mich aber irren.
Hier steht das auch so : https://serverfault.com/questions/1116483/thin-lvm-readonly-mode

 

[Iacov]

Mach doch mal ein memtest und checke die smartwerte der nvme

smart schaut (glaube ich) unverdächtig aus

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        60 Celsius
Available Spare:                    100%
Available Spare Threshold:          10%
Percentage Used:                    0%
Data Units Read:                    5,036,030 [2.57 TB]
Data Units Written:                 4,570,891 [2.34 TB]
Host Read Commands:                 40,065,308
Host Write Commands:                118,825,648
Controller Busy Time:               167
Power Cycles:                       23
Power On Hours:                     2,978
Unsafe Shutdowns:                   8
Media and Data Integrity Errors:    0
Error Information Log Entries:      1
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0

das einzige ist die "error log information" - da weiß ich aber (noch) nicht, wie ich an den log rankomm
hab testweise auch auf pve1 bei mir geschaut...da wird auch 1 bei dieser zeile angezeigt

 

[Iacov]

Ext4 ist ein altbewährtes und stabiles Linux Dateisystem und flach und KISS. Kannst auch XFS nutzen.
Trotzdem würde ich die VMs mal in einem Datenstore "VERZEICHNIS" laufen lassen - ohne den LVM Overhead.

Die Sicherungsdatei deiner VM sollte nur so groß sein, wie aktuelle auch seitens der VM genutzt wird. Also 30GB. Das kannst du ja unter Backups sehen. Wenn die Platte voll wäre, würde die Sicherung mit einem Fehler abbrechen, da kein Speicher verfügbar wäre.

Bei LVM wird (wenn ich das richtig im Kopf habe) zunächst die Platten R/O angesteuert und dann erst auf R/W umgestellt - kann mich aber irren.
Hier steht das auch so : https://serverfault.com/questions/1116483/thin-lvm-readonly-mode

ah super, das ist beruhigend, den thread habe ich nicht gefunden gehabt
gleichzeitig wirfts mich dahingehend zurück, weil lvdisplay dahingehend kein indikator für mich ist, ob alles passt oder nicht :/
das ist aktuell meine größte sorge - wie ich den konkreten zeitpunkt ermittle, ab wann etwas nicht funktioniert damit ich dann entsprechend die logs gezielt durchsuchen kann

ja, die backups sind nur so groß wie die vm-platte - aber zumindest für mich als laie schauts so aus, als würde der backup job die "ganzen" 150gb schreiben (wird halt ab den ersten 30gb deutlich schneller) und stellt dann am schluss fest das x% "sparse" sind
zb 201: 2024-06-21 04:35:59 INFO: backup is sparse: 103.11 GiB (68%) total zero data
normalerweise sollte das ja kein problem machen (und hat es ja lange auch nicht), da PVE ja mit dem overprovisioning umgehen kann...aber es ist mir nur als idee aufgekommen ob entweder eine miskonfiguration von mir oder ein bug dazu führt, dass PVE kurzzeitig denkt, dass es voll ist und damit dicht macht
es ist nur spannend weil in der GUI ja ausreciehdn platz angezeigt wird, dennoch kommts zu read only metadata...ohne, wie es sonst der übliche verdächtige wäre, dass ich i/o fehler um die ohren geschmissen bekomme