linux - mp3tag - puddletag
¿Cómo puedo simular un disco fallido durante la prueba? (6)
En una VM de Linux (estación de trabajo Vmware o similar), ¿cómo puedo simular una falla en un disco que funcionaba anteriormente?
Me ocurre una situación en la producción donde falla un disco (probablemente un problema de controlador, cable o firmware). Obviamente, esto no es predecible ni reproducible, quiero probar mi monitoreo para asegurarme de que se alerta correctamente.
Idealmente, me gustaría poder simular una situación en la que falla las escrituras pero las lecturas tienen éxito, así como una falla completa, es decir, la interfaz scsi reporta los errores al kernel.
El kernel de Linux proporciona una buena característica llamada "inyección de fallas"
echo 1 > /sys/block/vdd/vdd2/make-it-fail
Para configurar algunas de las opciones:
mkdir /debug
mount debugfs /debug -t debugfs
cd /debug/fail_make_request
echo 10 > interval # interval
echo 100 > probability # 100% probability
echo -1 > times # how many times: -1 means no limit
Para agregar a la respuesta de mark4o, también puede usar el asignador de dispositivos de Linux para generar dispositivos con fallas.
El dispositivo de retardo de Device Mapper se puede usar para enviar E / S de lectura y escritura del mismo bloque a diferentes dispositivos subyacentes (también puede retrasar esa E / S como su nombre indica). El dispositivo de error de Device Mapper se puede usar para generar errores permanentes cuando se accede a un bloque en particular. Al combinar los dos, puede crear un dispositivo donde las escrituras siempre fallan pero las lecturas siempre tienen éxito en un área determinada.
Lo anterior es un ejemplo más complicado de lo que se describe en la pregunta ¿ Simular un dispositivo de bloque defectuoso con errores de lectura? (Consulte https://.com/a/1871029 para ver un ejemplo simple de Device Mapper).
También hay una lista de mecanismos de inyección de fallas en el disco de Linux en el archivo especial que causa la pregunta de Unix y Linux sobre el error de E / S.
Puede usar el módulo del kernel scsi_debug para simular un disco RAM y admite todos los errores SCSI con opciones opts y every_nth .
Por favor, consulte este http://sg.danny.cz/sg/sdebug26.html
Ejemplo de error medio en el sector 4656:
[fge@Gris-Laptop ~]$ sudo modprobe scsi_debug opts=2 every_nth=1
[fge@Gris-Laptop ~]$ sudo dd if=/dev/sdb of=/dev/null
dd: error reading ‘/dev/sdb’: Input/output error
4656+0 records in
4656+0 records out
2383872 bytes (2.4 MB) copied, 0.021299 s, 112 MB/s
[fge@Gris-Laptop ~]$ dmesg|tail
[11201.454332] blk_update_request: critical medium error, dev sdb, sector 4656
[11201.456292] sd 5:0:0:0: [sdb] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[11201.456299] sd 5:0:0:0: [sdb] Sense Key : Medium Error [current]
[11201.456303] sd 5:0:0:0: [sdb] Add. Sense: Unrecovered read error
[11201.456308] sd 5:0:0:0: [sdb] CDB: Read(10) 28 00 00 00 12 30 00 00 08 00
[11201.456312] blk_update_request: critical medium error, dev sdb, sector 4656
Puede modificar las opciones opts y every_nth en tiempo de ejecución a través de sysfs:
echo 2 | sudo tee /sys/bus/pseudo/drivers/scsi_debug/opts
echo 1 | sudo tee /sys/bus/pseudo/drivers/scsi_debug/opts
También se pueden usar métodos proporcionados por los discos para realizar pruebas de error de medios. SCSI tiene un comando WRITE LONG que se puede usar para corromper un bloque al escribir datos con ECC no válido. SATA y NVMe también tienen comandos similares.
Para el caso más común (SATA), puede usar hdparm con --make-bad-sector para emplear ese comando, puede usar sg_write_long para SCSI y para NVMe puede usar nvme-cli con la opción write-uncor.
La gran ventaja que estos comandos tienen sobre otros métodos de inyección es que también se comportan como lo hace una unidad, con un impacto total de latencia y también la recuperación en una escritura en ese sector por reasignación. Esto incluye también los contadores de errores que se activan en la unidad.
La desventaja es que si lo hace demasiado para la misma unidad, sus contadores de errores aumentarán y SMART puede marcar el disco como defectuoso o puede agotar sus tablas de reasignación. Por lo tanto, úselo para pruebas manuales, pero si lo está ejecutando en pruebas automatizadas, no lo haga con demasiada frecuencia.
Una forma sencilla de hacer que un disco SCSI desaparezca con un kernel 2.6 es:
echo 1 > /sys/bus/scsi/devices/H:B:T:L/delete
(H: B: T: L es host, bus, destino, LUN). Sin embargo, para simular el caso de solo lectura, tendrá que usar los métodos de inyección de fallas que se mencionan en mark4o.
Hay varias capas en las que se puede simular un error de disco. Si está probando un solo programa de espacio de usuario, probablemente el enfoque más simple es interponer las llamadas apropiadas (por ejemplo, write() ) y hacer que a veces devuelvan un error. La biblioteca de inyección de fallas libfiu puede hacer esto usando su herramienta de fiu-run fallas.
Otro enfoque es utilizar un controlador de kernel que pueda pasar datos a / desde otro dispositivo, pero inyectar fallas en el camino. Luego puede montar el dispositivo y usarlo desde cualquier aplicación como si fuera un disco defectuoso. El controlador fsdisk es un ejemplo de esto.
También hay una infraestructura de inyección de fallas que se ha fusionado en el kernel de Linux, aunque probablemente necesitará reconfigurar su kernel para habilitarlo. Se documenta en Documentation/fault-injection/fault-injection.txt . Esto es útil para probar el código del kernel.
También es posible usar SystemTap para inyectar fallas en el nivel del kernel. Consulte La prueba de inyección de fallas SCSI y la inyección de fallas de kernel utilizando SystemTap .