☰

Estado de FreeBSD VMware y CAM: Error de estado SCSI

tag-icon • tag-icon vmware-esxi freebsd storage-area-network scsi
Estado de FreeBSD VMware y CAM: Error de estado SCSI

Estoy ejecutando FreeBSD 10.1-RELEASE-p19 en un VPS (VMware).

Mi ISP está experimentando un rápido crecimiento de datos y estos mensajes espontáneos comenzaron a aparecer en nuestros registros hace una semana.

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

A veces, el servidor pierde totalmente el contacto con el almacenamiento y luego entra en pánico y se reinicia. Esto suele ocurrir cada hora par, presumiblemente debido a un trabajo de rutina (migración/copia de seguridad).

Hasta que mi ISP haya agregado más sistema de almacenamiento, lo que reducirá la carga del almacenamiento, realmente quiero intentar hacer algo.

Encontré esto, pero no estoy seguro de cómo parchear/usar la información: https://svnweb.freebsd.org/base?view=revision&revision=278111

También encontré esto ( vfs.unmapped_buf_allowed=0), pero no estoy seguro de si podría estar relacionado. 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

gstatinformación cuando ocurren errores: ingrese la descripción de la imagen aquí

Cualquier idea, sugerencia o idea sería realmente muy apreciada.

¡Gracias!

Respuesta1

Si está utilizando VMWare, por lo que mpt(4) es puramente virtual, sugeriría cambiarlo a algo más simple, como ICH10.

De lo contrario, te sugiero que juegues con camcontrol tags, ya sea aumentando o disminuyendo la longitud de la cola.

Si elige reaprovisionar los discos usando otro controlador, tenga en cuenta que el cambio de controlador SAS -> SATA puede resultar en un cambio de nombre del dispositivo, probablemente /dev/daXse convierta en /dev/adaX, por lo que, a menos que esté usando zfs o montando sus discos mediante etiquetas de disco, tendrá que editar /etc/fstab.

En cuanto a su gstatresultado, claramente hay algo mal en él, probablemente debido a la naturaleza del soporte del entorno virtual en FreeBSD. Una carga del 600% es una tontería. Le sugiero que informe esto en FreeBSD Bugzilla.

PD: El consejo para cambiar el tipo de controlador de aprovisionamiento de disco sigue vigente. PPS O. O intentaría reducir la longitud de la cola de mpt(4) a 128 o incluso 64.

información relacionada