[FAILED] Failed to mount /mnt/pve/CephFS

dejhost · Feb 10, 2023

Hallo Zusammen,
einer meiner proxmox-server streckt hin und wieder die Flügel:

Code:

[FAILED] Failed to mount /mnt/pve/CephFS

steht mehrfach auf dem Monitor-Konsole. Eingaben sind nicht möglich. Über das Web-Interface ist er nicht mehr zu erreichen. Erst nach 3 Sekunden Power-knopf schaltet er aus, und ich kann ihn neu starten. Dann läuft vorerst alles wie es soll.

Könntet ihr mir bitte helfen herauszufinden, warum das sporadisch passiert, und wie ich das vermeide? Im folgenden einige Infos:
Proxmox-Version ist 7.3-4.

Code:

root@s301:~# ceph -s
  cluster:
    id:     93764ec6-4ae0-46d7-b3ac-5ba31a407168
    health: HEALTH_WARN
            20 pgs not deep-scrubbed in time
 
  services:
    mon: 1 daemons, quorum s301 (age 13m)
    mgr: s301(active, since 13m)
    mds: 1/1 daemons up
    osd: 2 osds: 2 up (since 11m), 2 in (since 7w)
 
  data:
    volumes: 1/1 healthy
    pools:   4 pools, 97 pgs
    objects: 1.75M objects, 6.7 TiB
    usage:   13 TiB used, 4.9 TiB / 18 TiB avail
    pgs:     96 active+clean
             1  active+clean+scrubbing+deep
 
  io:
    client:   5.7 KiB/s wr, 0 op/s rd, 0 op/s wr

Code:

root@s301:~# cat /etc/fstab
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/pve/root / ext4 errors=remount-ro 0 1
/dev/pve/swap none swap sw 0 0
proc /proc proc defaults 0 0

Herzlichen Dank schon mal für die Hilfe.

gurubert · Feb 11, 2023

Du solltest mindestens drei MONs ausrollen. Nur einer garantiert den Ausfall, wenn diese Maschine gerade nicht verfügbar ist.

Genauso beim MDS. Auch da gibt es momentan nur einen. Besser wären zwei (einer als standby). Und dasselbe für den MGR.

Oder ist das ein Proxmox-"Cluster" mit nur einem Host? Dann gar kein Ceph verwenden. Da reicht LVM oder ZFS für den lokalen Speicher.

dejhost · Feb 12, 2023

gurubert said:
Du solltest mindestens drei MONs ausrollen. Nur einer garantiert den Ausfall, wenn diese Maschine gerade nicht verfügbar ist.

Genauso beim MDS. Auch da gibt es momentan nur einen. Besser wären zwei (einer als standby). Und dasselbe für den MGR.

Oder ist das ein Proxmox-"Cluster" mit nur einem Host? Dann gar kein Ceph verwenden. Da reicht LVM oder ZFS für den lokalen Speicher.

Danke für die Tipps.

Der server ist noch im Aufbau, und wird entsprechend erweitert.

Kannst du mir helfen herauszufinden, was das Problem verursachtt?

gurubert · Feb 12, 2023

Wie geschrieben, Crph braucht mindestens drei, besser fünf Knoten. Wenn Du nur einen hast, dann nimm LVM (auch thin) oder ZFS als Storage.

dejhost · Feb 14, 2023

gurubert said:
Du solltest mindestens drei MONs ausrollen. Nur einer garantiert den Ausfall, wenn diese Maschine gerade nicht verfügbar ist.

Genauso beim MDS. Auch da gibt es momentan nur einen. Besser wären zwei (einer als standby). Und dasselbe für den MGR.

Oder ist das ein Proxmox-"Cluster" mit nur einem Host? Dann gar kein Ceph verwenden. Da reicht LVM oder ZFS für den lokalen Speicher.

Sorry, sehe erst jetzt, dass ich Deine Gegenfrage nicht beantwortet habe: Das ist tatsächlich ein cluster mit nur einem host. Soll aber (eher langfristig) durch weitere Knoten erweitert werden. Daher ceph.

So ganz kann ich Deiner Argumentation nicht folgen: wieso sollte ich ein mount-problem bekommen, wenn ich nur einen Knoten habe?

Hier mein syslog gepostet. Heute, am 14.02.23 um 17:51 musste ich den Server erneut per knopf-druck abschalten und neustarten... https://pastebin.com/cF6psm2j

Falk R. · Feb 14, 2023

Hi,
deine Meldung:

health: HEALTH_WARN
            20 pgs not deep-scrubbed in time

deutet auf zu langsame Disks hin. Wenn er das Scrubbing nicht durchführen kann, liegt es in der Regel daran, dass die Disks die ganze Zeit ausgelastet sind.
Hast du da HDDs?

Neobin · Feb 15, 2023

dejhost said:
Das ist tatsächlich ein cluster mit nur einem host. Soll aber (eher langfristig) durch weitere Knoten erweitert werden. Daher ceph.

Mehr als fraglich, ob das Herumfahren mit einem Auto mit nur einem Rad dran so sinnig ist...

YMMV

dejhost · Feb 15, 2023

SkyDiver79 said:
Hi,
deine Meldung:
health: HEALTH_WARN 20 pgs not deep-scrubbed in time
deutet auf zu langsame Disks hin. Wenn er das Scrubbing nicht durchführen kann, liegt es in der Regel daran, dass die Disks die ganze Zeit ausgelastet sind.
Hast du da HDDs?

Hallo SkyDiver,

Das sind 2x 10TB HDD von WD:, sowie 1 x NVME mit 1TB - hauptsächlich für die Betriebssysteme der VM's und die Container. Die SMART-werte:

Code:

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        28 Celsius
Available Spare:                    100%
Available Spare Threshold:          5%
Percentage Used:                    2%
Data Units Read:                    45,231,360 [23.1 TB]
Data Units Written:                 40,824,542 [20.9 TB]
Host Read Commands:                 624,373,412
Host Write Commands:                732,155,094
Controller Busy Time:               1,602
Power Cycles:                       588
Power On Hours:                     12,257
Unsafe Shutdowns:                   121
Media and Data Integrity Errors:    0
Error Information Log Entries:      699
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0

Siehst Du etwas auffälliges? Zugriff auf Daten seitens Nutzer sollte nur sehr begrentzt erfolgen. Daher kann keine Beanspruchung rühren.

Hier nochmal aktueller output über ceph:

Code:

root@s301:~# ceph -s
  cluster:
    id:     93764ec6-4ae0-46d7-b3ac-5ba31a407168
    health: HEALTH_OK
 
  services:
    mon: 1 daemons, quorum s301 (age 20h)
    mgr: s301(active, since 20h)
    mds: 1/1 daemons up
    osd: 2 osds: 2 up (since 20h), 2 in (since 8w)
 
  data:
    volumes: 1/1 healthy
    pools:   4 pools, 97 pgs
    objects: 1.76M objects, 6.7 TiB
    usage:   13 TiB used, 4.8 TiB / 18 TiB avail
    pgs:     97 active+clean
 
  io:
    client:   7.1 MiB/s rd, 4.3 MiB/s wr, 69 op/s rd, 19 op/s wr

Danke für Deine Hilfe.

Falk R. · Feb 15, 2023

Wenn du den Bluestore (Metadaten) mit auf den HDDs hast weil du keine SSD dafür hast, wird das extrem langsam, mit allen Seiteneffekten. Dann würde ich lieber ein ZFS Mirror über die HDDs machen. Erweitern kannst du den Cluster trotzdem jederzeit und wenn du die nächsten Knoten vernünftig ausstattest, incl. SSD. Kannst du jederzeit wieder auf Ceph wechseln.
Übrigens ich nutze Ceph nur all Flash. Bei mir kommen keine HHDs mehr rein.

dejhost · Mar 30, 2023

Entschuldigt die lange Schreibpause.
ich habe zwischenzeitlich den Prozessor ausgetauscht, Multi-Threading im Bios ausgeschaltet, den RAM-geshuffelt... und schlussendlich cephfs abgeschafft. Die ursprüngliche Fehlermeldung ist somit verschwunden. Der Prozessor ist inzwischen wieder der Originale.

Leider läuft der Server jetzt noch schlechter als zuvor: D.h. konkret Innerhalb von 1-2 Tagen:

Ich bekomme keine Antwort auf meinen Ping.
Auf dem lokalen Monitor sehe ich den üblichen proxmox startbildschirm mit login, aber er reagiert auf keine Tastatureingabe.
3-Sekunden-Power drücken ist alles was bleibt.

Das log verlinke ich unten. Vor jedem (unfreiwliggem) reboot fallen mir Einträge wie dieser hier auf:

Mar 29 09:08:45 s301 smartd[807]: Device: /dev/sdb [SAT], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 68 to 82

Deshalb habe ich gestern Abend alle Festplatten einen Test unterzogen:

Code:

smartctl -t long /dev/sdb

Ca. 8 Stunden später hat sich der Sever dann wieder aufgehangen. Die SMART-Werte sagen, dass die Tests ohne Fehler bestanden wurden.

Ein weitere Besonderheit: Einige der VM's weigern sich nach einem Neustart des Servers automatisch zu booten. Manuelll klappt es dann aber immer.

Code:

TASK ERROR: start failed: command '/usr/bin/kvm -id 104 -name 'S3-NC,debug-threads=on' -no-shutdown -chardev 'socket,id=qmp,path=/var/run/qemu-server/104.qmp,server=on,wait=off' -mon 'chardev=qmp,mode=control' -chardev 'socket,id=qmp-event,path=/var/run/qmeventd.sock,reconnect=5' -mon 'chardev=qmp-event,mode=control' -pidfile /var/run/qemu-server/104.pid -daemonize -smbios 'type=1,uuid=f6de05a4-98c4-40d7-87f3-d34bbada58f9' -smp '4,sockets=1,cores=4,maxcpus=4' -nodefaults -boot 'menu=on,strict=on,reboot-timeout=1000,splash=/usr/share/qemu-server/bootsplash.jpg' -vnc 'unix:/var/run/qemu-server/104.vnc,password=on' -cpu kvm64,enforce,+kvm_pv_eoi,+kvm_pv_unhalt,+lahf_lm,+sep -m 8196 -device 'pci-bridge,id=pci.1,chassis_nr=1,bus=pci.0,addr=0x1e' -device 'pci-bridge,id=pci.2,chassis_nr=2,bus=pci.0,addr=0x1f' -device 'vmgenid,guid=563d53ec-4adb-4881-a9f9-dfb33b35f61b' -device 'piix3-usb-uhci,id=uhci,bus=pci.0,addr=0x1.0x2' -device 'usb-tablet,id=tablet,bus=uhci.0,port=1' -device 'VGA,id=vga,bus=pci.0,addr=0x2' -device 'virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3,free-page-reporting=on' -iscsi 'initiator-name=iqn.1993-08.org.debian:01:f178f4534825' -device 'virtio-scsi-pci,id=scsihw0,bus=pci.0,addr=0x5' -drive 'file=/dev/pve/vm-104-disk-0,if=none,id=drive-scsi0,format=raw,cache=none,aio=io_uring,detect-zeroes=on' -device 'scsi-hd,bus=scsihw0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0,id=scsi0,bootindex=100' -drive 'file=rbd:Raid1/vm-104-disk-1:conf=/etc/pve/ceph.conf:id=admin:keyring=/etc/pve/priv/ceph/Raid1.keyring,if=none,id=drive-virtio1,format=raw,cache=none,aio=io_uring,detect-zeroes=on' -device 'virtio-blk-pci,drive=drive-virtio1,id=virtio1,bus=pci.0,addr=0xb' -netdev 'type=tap,id=net0,ifname=tap104i0,script=/var/lib/qemu-server/pve-bridge,downscript=/var/lib/qemu-server/pve-bridgedown,vhost=on' -device 'virtio-net-pci,mac=7E:18:53:5D:BA:62,netdev=net0,bus=pci.0,addr=0x12,id=net0,rx_queue_size=1024,tx_queue_size=1024,bootindex=101' -machine 'type=pc+pve0'' failed: got timeout

Hier findet ihr das log in 2 Teile teilen:

Könntet ihr mir helfen die Ursache für das Einfrieren zu identifizieren und zu beheben? Ich tippe mal, dass die ursprüngliche Fehlermeldung "failed to mount cpehfs" nur ein Symptom war....

Falk R. · Mar 31, 2023

dejhost said:
Mar 29 09:08:45 s301 smartd[807]: Device: /dev/sdb [SAT], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 68 to 82

Wenn das die letzte Meldung vor dem Aufhängen ist, vermute ich, die Disk ist defekt und steigt dann aus. Das hat zur Folge, dass der Host ganz schnell einfriert wenn die Disk nicht mehr antwortet.
Prefailure heißt auch immer, die Disk fällt demnächst komplett aus.

dejhost · Mar 31, 2023

nicht unmittelbar die letzte Meldung vor dem reboot, aber kurz zuvor häufen sich diese Meldungen mit SMART-Werten. Allerdings tauchen da alle Festplatten auf, deshalb bin ich noch nicht so ganz überzeugt. sdb scheint die mit den grössten Sprüngen zu sein (s.o.). Sind die Sprünge von sda schon "zu viel"?

Code:

Mar 29 08:38:45 s301 smartd[807]: Device: /dev/sda [SAT], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 76 to 83
Mar 29 08:38:45 s301 smartd[807]: Device: /dev/sda [SAT], SMART Usage Attribute: 195 Hardware_ECC_Recovered changed from 76 to 83

Falk R. · Mar 31, 2023

dejhost said:

Code:

Mar 29 08:38:45 s301 smartd[807]: Device: /dev/sda [SAT], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 76 to 83
Mar 29 08:38:45 s301 smartd[807]: Device: /dev/sda [SAT], SMART Usage Attribute: 195 Hardware_ECC_Recovered changed from 76 to 83

Die ECC recovered sind nicht so schlimm aber als Vorzeichen zu sehen.
Die RAW Read heißt, der Block ist gar nicht mehr lesbar. Die sollten sich nicht so sehr häufen. Ab 200 Errors bekommst du bei Enterprise Servern mit Wartung direkt neue.
Zählt für die Hersteller schon als Totalschaden.

dejhost · Apr 3, 2023

Verflixt. Jetzt hat er zwar einige Tage durchgehalten, heute dann aber wieder eingefroren:

Code:

Apr 02 16:29:40 s301 smartd[827]: Device: /dev/sda [SAT], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 71 to 81
Apr 02 16:29:40 s301 smartd[827]: Device: /dev/sda [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 64 to 65
Apr 02 16:29:40 s301 smartd[827]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 36 to 35
Apr 02 16:29:40 s301 smartd[827]: Device: /dev/sda [SAT], SMART Usage Attribute: 195 Hardware_ECC_Recovered changed from 71 to 81
Apr 02 16:29:41 s301 smartd[827]: Device: /dev/sdb [SAT], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 79 to 83
Apr 02 16:29:41 s301 smartd[827]: Device: /dev/sdb [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 67 to 68
Apr 02 16:29:41 s301 smartd[827]: Device: /dev/sdb [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 33 to 32
Apr 02 16:29:41 s301 smartd[827]: Device: /dev/sdb [SAT], SMART Usage Attribute: 195 Hardware_ECC_Recovered changed from 79 to 83
Apr 02 16:59:40 s301 smartd[827]: Device: /dev/sda [SAT], SMART Prefailure Attribute: 1 Raw_Read_Error_Rate changed from 81 to 82
Apr 02 16:59:40 s301 smartd[827]: Device: /dev/sda [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 65 to 67
Apr 02 16:59:40 s301 smartd[827]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 35 to 33
Apr 02 16:59:40 s301 smartd[827]: Device: /dev/sda [SAT], SMART Usage Attribute: 195 Hardware_ECC_Recovered changed from 81 to 82
Apr 02 16:59:40 s301 smartd[827]: Device: /dev/sdb [SAT], SMART Usage Attribute: 190 Airflow_Temperature_Cel changed from 68 to 70
Apr 02 16:59:40 s301 smartd[827]: Device: /dev/sdb [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 32 to 30
Apr 02 17:17:01 s301 CRON[1307890]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Apr 02 17:17:01 s301 CRON[1307891]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Apr 02 17:17:01 s301 CRON[1307890]: pam_unix(cron:session): session closed for user root
-- Reboot --
Apr 02 21:55:15 s301 kernel: Linux version 5.19.17-2-pve (build@proxmox) (gcc (Debian 10.2.1-6) 10.2.1 20210110,

die RAW-Reads sind immer um die 80, so dass ich das als Grund ausscheide. Sonst eine Idee

Falk R. · Apr 3, 2023

Auch wenn die Werte nicht hoch gehen, kommen die Meldungen doch recht häufig. Gibt es zufällig eine neue Firmware vom Hersteller?
Ich würde auch von dem 5.19er Kernel weg gehen, schon mal den 6.2 probiert?

dejhost · Apr 9, 2023

Ich habe in der letzten Woche weiter Daten auf den serber migriert und ceph eine zusätzliche 18TB-HDD gegeben. Nachdem mehrere Tage lang die Daten neu verteilt wurden (ohne ein weiteres mal einzufrieren) ist er heute wieder eingefroren. Seltsamerweise steht diesmal nichts von "reboot" und den SMART-werten im log:

Code:

2023-04-09T01:14:40.463402+0200 mgr.s301 (mgr.3034108) 265122 : cluster [DBG] pgmap v265210: 33 pgs: 1 active+clean+scrubbing+deep, 32 active+clean; 8.3 TiB data, 17 TiB used, 18 TiB / 35 TiB avail; 0 B/s rd, 27 KiB/s wr, 3 op/s
2023-04-09T01:14:41.854930+0200 osd.0 (osd.0) 473 : cluster [DBG] 1.1c deep-scrub starts
2023-04-09T01:14:42.463797+0200 mgr.s301 (mgr.3034108) 265123 : cluster [DBG] pgmap v265211: 33 pgs: 1 active+clean+scrubbing+deep, 32 active+clean; 8.3 TiB data, 17 TiB used, 18 TiB / 35 TiB avail; 0 B/s rd, 27 KiB/s wr, 3 op/s
2023-04-09T01:14:43.904255+0200 osd.0 (osd.0) 474 : cluster [DBG] 1.10 scrub starts
2023-04-09T01:14:44.464322+0200 mgr.s301 (mgr.3034108) 265124 : cluster [DBG] pgmap v265212: 33 pgs: 1 active+clean+scrubbing+deep, 32 active+clean; 8.3 TiB data, 17 TiB used, 18 TiB / 35 TiB avail; 0 B/s rd, 29 KiB/s wr, 3 op/s
2023-04-09T01:14:45.924178+0200 osd.0 (osd.0) 475 : cluster [DBG] 1.1c deep-scrub starts
2023-04-09T01:14:46.464598+0200 mgr.s301 (mgr.3034108) 265125 : cluster [DBG] pgmap v265213: 33 pgs: 1 active+clean+scrubbing+deep, 32 active+clean; 8.3 TiB data, 17 TiB used, 18 TiB / 35 TiB avail; 0 B/s rd, 26 KiB/s wr, 2 op/s
2023-04-09T01:14:46.920279+0200 osd.0 (osd.0) 476 : cluster [DBG] 1.10 scrub starts
2023-04-09T19:46:21.211087+0200 mon.s301 (mon.0) 1 : cluster [INF] mon.s301 is new leader, mons s301 in quorum (ranks 0)
2023-04-09T19:46:21.211161+0200 mon.s301 (mon.0) 2 : cluster [DBG] monmap e1: 1 mons at {s301=[v2:192.168.1.89:3300/0,v1:192.168.1.89:6789/0]}
2023-04-09T19:46:21.211733+0200 mon.s301 (mon.0) 3 : cluster [DBG] fsmap
2023-04-09T19:46:21.211752+0200 mon.s301 (mon.0) 4 : cluster [DBG] osdmap e1486: 3 total, 3 up, 3 in
2023-04-09T19:46:21.218034+0200 mon.s301 (mon.0) 5 : cluster [DBG] mgrmap e465: s301(active, since 6d)
2023-04-09T19:46:25.035390+0200 mon.s301 (mon.0) 6 : cluster [INF] Active manager daemon s301 restarted
2023-04-09T19:46:25.041856+0200 mon.s301 (mon.0) 7 : cluster [INF] Activating manager daemon s301
2023-04-09T19:46:25.053126+0200 mon.s301 (mon.0) 8 : cluster [DBG] osdmap e1487: 3 total, 3 up, 3 in
2023-04-09T19:46:25.103945+0200 mon.s301 (mon.0) 9 : cluster [DBG] mgrmap e466: s301(active, starting, since 0.0621693s)
2023-04-09T19:46:25.134086+0200 mon.s301 (mon.0) 18 : cluster [INF] Manager daemon s301 is now available
2023-04-09T19:46:26.153058+0200 mon.s301 (mon.0) 20 : cluster [DBG] mgrmap e467: s301(active, since 1.11128s)
2023-04-09T19:46:26.204382+0200 mon.s301 (mon.0) 21 : cluster [INF] Manager daemon s301 is unresponsive.  No standby daemons available.
2023-04-09T19:46:26.204562+0200 mon.s301 (mon.0) 22 : cluster [WRN] Health check failed: no active mgr (MGR_DOWN)
2023-04-09T19:46:26.215748+0200 mon.s301 (mon.0) 23 : cluster [DBG] osdmap e1488: 3 total, 3 up, 3 in
2023-04-09T19:46:26.227346+0200 mon.s301 (mon.0) 24 : cluster [DBG] mgrmap e468: no daemons active (since 0.0229674s)
2023-04-09T19:46:43.983164+0200 mon.s301 (mon.0) 25 : cluster [INF] Activating manager daemon s301
2023-04-09T19:46:44.033518+0200 mon.s301 (mon.0) 26 : cluster [INF] Health check cleared: MGR_DOWN (was: no active mgr)
2023-04-09T19:46:44.051091+0200 mon.s301 (mon.0) 27 : cluster [DBG] mgrmap e469: s301(active, starting, since 0.0680933s)
2023-04-09T19:46:44.074282+0200 mon.s301 (mon.0) 33 : cluster [INF] Manager daemon s301 is now available
2023-04-09T19:46:45.100617+0200 mon.s301 (mon.0) 35 : cluster [DBG] mgrmap e470: s301(active, since 1.11762s)
2023-04-09T19:46:46.116079+0200 mon.s301 (mon.0) 36 : cluster [DBG] mgrmap e471: s301(active, since 2s)
2023-04-09T19:47:04.104135+0200 mon.s301 (mon.0) 37 : cluster [INF] Health check cleared: PG_NOT_DEEP_SCRUBBED (was: 1 pgs not deep-scrubbed in time)
2023-04-09T19:47:04.104161+0200 mon.s301 (mon.0) 38 : cluster [INF] Cluster is now healthy
2023-04-09T19:47:04.053707+0200 mgr.s301 (mgr.3344112) 1 : cluster [DBG] pgmap v2: 33 pgs: 33 unknown; 0 B data, 0 B used, 0 B / 0 B avail

Interessant, dass er sich in dem Moment aufhängt, in dem OSD.0 gescrubt werden soll. Was meint ihr dazu?

Ich habe heute auf den kernel auf 6.2 ge-updatet. Mal schauen, ob das etwas ändert.

Zu möglichen firmware updates: Die NVME (Gigabyte GP-ASM2NE6100TTTD) auf der proxmox läuft hat eine Firmware-version "EGFM11.3". Das hier ist die HP für Firmware. Ich werde nicht ganz schlau daraus, ob ich die aktuelle habe.
Für die HDD's gibt es jedenfalls kein update.

Bin für jeden weiteren Input dankbar...

Falk R. · Apr 9, 2023

dejhost said:
Interessant, dass er sich in dem Moment aufhängt, in dem OSD.0 gescrubt werden soll. Was meint ihr dazu?

Welche DIsk ist denn OSD.0? Entweder die ist extrem langsam oder hat Lesefehler, dann wäre das Einfrieren erklärbar.

dejhost said:
Zu möglichen firmware updates: Die NVME (Gigabyte GP-ASM2NE6100TTTD) auf der proxmox läuft hat eine Firmware-version "EGFM11.3". Das hier ist die HP für Firmware. Ich werde nicht ganz schlau daraus, ob ich die aktuelle habe.
Für die HDD's gibt es jedenfalls kein update.

Einfach mal das Update laufen lassen, das prüft welche Version drauf ist und wenn es die aktuelle Version ist, fragt er maximal ob du das Update überschreiben willst, dann kannst du ja abbrechen.

gurubert · Apr 10, 2023

Der Ceph-Cluster hat nur einen MON. Wenn der nicht läuft, geht halt gar nichts mehr.

Falk R. · Apr 10, 2023

Das scheint ja auch nur 1 Host zu sein. Zum Spielen und Testen geht das ja.

dejhost · Apr 10, 2023

Falk R. said:
Welche DIsk ist denn OSD.0? Entweder die ist extrem langsam oder hat Lesefehler, dann wäre das Einfrieren erklärbar.

Einfach mal das Update laufen lassen, das prüft welche Version drauf ist und wenn es die aktuelle Version ist, fragt er maximal ob du das Update überschreiben willst, dann kannst du ja abbrechen.

Die OSD.0 ist die sda. Ich könnte ja alle VM's und CT's heruntefahren und einen scrub der sda anstossen. Wenn der Sever sich wieder aufhängt, dann hätten wir den Verdacht erhärtet... wie initiiere ich eine scrub?

Kann ich das update-tool von gigabyte auf einer Windows-VM in Proxmox laufen lassen?

Danke Euch.

[FAILED] Failed to mount /mnt/pve/CephFS

Member

Famous Member

Member

Famous Member

Member

Distinguished Member

Distinguished Member

Member

Distinguished Member

Member

Distinguished Member

Member

Distinguished Member

Member

Distinguished Member

Member

Distinguished Member

Famous Member

Distinguished Member

Member