☰

FreeBSD VMware- und CAM-Status: SCSI-Statusfehler

tag-icon • tag-icon vmware-esxi freebsd storage-area-network scsi
FreeBSD VMware- und CAM-Status: SCSI-Statusfehler

Ich verwende FreeBSD 10.1-RELEASE-p19 auf einem VPS (VMware).

Bei meinem ISP ist ein schnelles Datenwachstum zu verzeichnen und diese Meldungen tauchten vor einer Woche plötzlich in unseren Protokollen auf.

Sep 25 09:00:50 srv03 kernel: (da0:mpt0:0:0:0): SCSI status: Busy
Sep 25 09:00:50 srv03 kernel: (da0:mpt0:0:0:0): Retrying command
Sep 25 09:00:50 srv03 kernel: (da0:mpt0:0:0:0): WRITE(10). CDB: 2a 00 03 f9 6c 22 00 00 40 00
Sep 25 09:00:50 srv03 kernel: (da0:mpt0:0:0:0): CAM status: SCSI Status Error

Manchmal verliert der Server den Kontakt zum Speicher vollständig und gerät dann in Panik und startet neu. Dies geschieht oft jede gerade Stunde, vermutlich aufgrund eines Routinejobs (Migration/Backup).

Bis mein ISP weitere Speichersysteme hinzugefügt hat, die die Speicherlast verringern, möchte ich wirklich versuchen, etwas zu unternehmen.

Ich habe dies gefunden, bin mir aber nicht sicher, wie ich die Informationen patchen/verwenden soll: https://svnweb.freebsd.org/base?view=revision&revision=278111

Ich habe auch dies ( vfs.unmapped_buf_allowed=0) gefunden, bin mir aber nicht sicher, ob das damit zusammenhängen könnte? https://www.freebsd.org/releases/10.1R/errata.html#open-issues

camcontrol tags da0 -v

(pass1:mpt0:0:0:0): dev_openings  127
(pass1:mpt0:0:0:0): dev_active    0
(pass1:mpt0:0:0:0): devq_openings 127
(pass1:mpt0:0:0:0): devq_queued   0
(pass1:mpt0:0:0:0): held          -1
(pass1:mpt0:0:0:0): mintags       2
(pass1:mpt0:0:0:0): maxtags       255

gstatInfos bei auftretenden Fehlern: Bildbeschreibung hier eingeben

Ich wäre für alle Gedanken, Hinweise und Ideen wirklich sehr, sehr dankbar.

Danke!

Antwort1

Wenn Sie VMWare verwenden und mpt(4) daher rein virtuell ist, würde ich vorschlagen, es durch etwas Einfacheres wie ICH10 zu ändern.

Andernfalls schlage ich vor camcontrol tags, dass Sie damit experimentieren und die Warteschlangenlänge entweder erhöhen oder verringern.

Wenn Sie sich dafür entscheiden, Festplatten mit einem anderen Treiber neu zu provisionieren, beachten Sie, dass die Änderung des SAS- auf den SATA-Controller eine Änderung der Gerätebenennung zur Folge haben kann (wahrscheinlich /dev/daXwird ) /dev/adaX. Wenn Sie also nicht zfs verwenden oder Ihre Festplatten über Festplattenbezeichnungen mounten, müssen Sie bearbeiten /etc/fstab.

Was Ihre gstatAusgabe betrifft, ist damit eindeutig etwas nicht in Ordnung, wahrscheinlich liegt es an der Art der Unterstützung virtueller Umgebungen in FreeBSD. 600 % Auslastung sind Unsinn. Ich schlage vor, Sie melden dies im FreeBSD-Bugzilla.

PS: Der Rat, den Disk Provisioning Controller-Typ zu ändern, gilt weiterhin. PPS Oder. Oder ich würde versuchen, die Warteschlangenlänge des mpt(4) auf 128 oder sogar 64 zu erhöhen.

verwandte Informationen