Archivo especial que causa error de E / S

Quiero probar automáticamente si una pieza de software reacciona como se esperaba si un archivo esencial de SQLite DB no se puede leer (causando un error de E / S). Exactamente eso sucedió hace unos días en un cliente. Lo arreglamos manualmente, pero ahora quiero crear un código automático para arreglarlo y necesito acceso a un archivo roto para probarlo.

Como todo en Unix es un archivo, sospeché que podría haber un archivo especial que siempre causa errores de E / S cuando uno intenta leerlo (por ejemplo, en / dev).

Algunos archivos similares (imo) serían:

• /dev/full que siempre dice "No queda espacio en el dispositivo" si intentas escribirlo
• /dev/null y /dev/zero

así que supuse que solo tenía que haber un archivo como ese (pero aún no he encontrado uno).

¿Alguien conoce ese archivo o cualquier otro método para obtener el resultado deseado (una imagen de partición intencionalmente defectuosa, un contenedor alrededor de open () usando LD_PRELOAD, ...)?
¿Cuál es la mejor manera de ir aquí?

Puede usar dmsetuppara crear un dispositivo de mapeador de dispositivos usando los objetivos erroro flakeypara simular fallas.

dmsetup create test --table '0 123 flakey 1 0 /dev/loop0'

Donde 123 es la longitud del dispositivo, en sectores y / dev / loop0 es el dispositivo original en el que desea simular errores. Por error, no necesita los argumentos posteriores ya que siempre devuelve un error.

Ya hay un gran conjunto de respuestas sobre Stack Overflow y Server Fault, pero faltaban algunas técnicas. Para hacer la vida más fácil, aquí hay una lista de mecanismos de inyección de fallas de E / S de dispositivos de bloques VM / Linux / sistema de archivos Linux / biblioteca de espacio de usuario de Linux:

• Utilice los dispositivos error / flakey / delay / dm-dust de Device Mapper para devolver errores / daños de, o retrasar / dividir las E / S en un dispositivo de bloque sintetizado (kernel, requiere que el kernel se haya construido con soporte de mapeador de dispositivos, módulos de mapeo de dispositivos adicionales apropiados ( dm-dust solo está disponible en kernel> = 5.2) y para tener bits de espacio de usuario del mapeador de dispositivos).
• Utilice la personalidad defectuosa de md para realizar una inyección de falla periódica en un dispositivo de bloque sintetizado. Consulte la --layoutopción de la página de manual mdadm para saber cómo configurarlo (kernel y bits de espacio de usuario mdadm).
• Use libfiu para realizar la inyección de fallas en las llamadas de API POSIX (espacio de usuario, se puede usar con LD_PRELOAD).
• Use el inyector de fallas del kernel de Linux para inyectar un error en el dispositivo de bloque subyacente (kernel, requiere que se haya construido el kernel FAIL_MAKE_REQUEST=y).
• Usar SystemTap para hacer la inyección de fallas (kernel, requiere que se haya construido un kernel con muchas cosas ).
• Inyecte fallas del sistema de archivos usando CharybdeFS o PetardFS (espacio de usuario a través de FUSE).
• Cree un dispositivo de bloque sintetizado utilizando el controlador scsi_debug de Linux que realiza la inyección de fallas (kernel).
• Ejecute su sistema dentro de QEMU y use QEMU para inyectar errores de dispositivos de bloque usando el controlador blkdebug (VM).
• Cree un dispositivo de bloque sintetizado a través de las opciones del dispositivo null_blk para inyectar fallas (kernel> = 4.14 pero las opciones como las probabilidades de tiempo de espera no llegaron hasta 4.17 y requieren que se haya construido el kernel BLK_DEV_NULL_BLK_FAULT_INJECTION=y).
• Cree un dispositivo de bloqueo de red sintetizado que se sirve al host a través de filtros NBDkit como delayo errory luego adjunte un dispositivo de bloqueo a través de nbd-client(kernel + NBD userspace bits, kernel> = 4.18 construido con soporte NBD, nbdclient> = 3.18 y nbdkit> = 1.8.1 recomendado: vea el video de demostración de NBDKit alrededor de los 20 minutos).

Dato adicional : SQLite tiene un controlador VFS para simular errores para que pueda obtener una buena cobertura de prueba.

Relacionado:

• ¿Cómo puedo simular un disco fallido durante la prueba?
• ¿Simular un dispositivo de bloque defectuoso con errores de lectura?
• Generar un error de lectura
• ¿Causar intencionalmente un error de E / S en Linux?

Desea un mecanismo de inyección de fallas para E / S.

En Linux, aquí hay un método que no requiere ninguna configuración previa y genera un error inusual (no EIO "Error de entrada / salida" sino ESRCH "No existe tal proceso"):

cat /proc/1234/mem

donde 1234 es el PID de un proceso que se ejecuta como el mismo usuario que el proceso que está probando, pero no ese proceso en sí. Créditos a rubasov para pensar de /proc/$pid/mem.

Si usa el PID del proceso en sí, obtendrá EIO, pero solo si está leyendo desde un área que no está asignada en la memoria del proceso. La primera página nunca se asigna, por lo que está bien si lee el archivo secuencialmente, pero no es adecuado para un proceso de base de datos que busca directamente en el medio del archivo.

Con algo más de configuración como root, puede aprovechar el mapeador de dispositivos para crear archivos con sectores válidos y sectores defectuosos.

Otro enfoque sería implementar un pequeño sistema de archivos FUSE . EIO es el código de error predeterminado cuando el controlador del sistema de archivos del espacio de usuario hace algo mal, por lo que es fácil de lograr. Tanto los enlaces de Perl como los de Python vienen con ejemplos para comenzar, puede escribir rápidamente un sistema de archivos que refleje principalmente los archivos existentes pero inyecta un EIO en lugares cuidadosamente seleccionados. Existe un sistema de archivos de este tipo: petardfs ( artículo ), no sé qué tan bien funciona fuera de la caja.

Otro método más es un LD_PRELOADenvoltorio. Uno existente es Libfiu (inyección de fallas en el espacio de usuario). Funciona precargando una biblioteca que sobrecarga las llamadas a la API POSIX. Puede escribir directivas simples o código C arbitrario para anular el comportamiento normal.

La solución es mucho más fácil si está bien usar un archivo de dispositivo como "archivo con errores de E / S". Mi propuesta es para aquellos casos en los que un archivo normal tendrá tales errores.

> dd if=/dev/zero of=/path/to/ext2.img bs=10M count=10
> losetup /dev/loop0 /path/to/ext2.img
> blockdev --getsz /dev/loop0
204800
> echo "0 204800 linear /dev/loop0 0" | dmsetup create sane_dev
> mke2fs /dev/mapper/sane_dev # ext2 reicht
> mount -t ext2 /dev/mapper/sane_dev /some/where
> dd if=/dev/zero of=/some/where/unreadable_file bs=512 count=4
> hdparm --fibmap /some/where/unreadable_file
/mnt/tmp/unreadable_file:
 filesystem blocksize 1024, begins at LBA 0; assuming 512 byte sectors.
 byte_offset  begin_LBA    end_LBA    sectors
           0       2050       2053          4
> umount /dev/mapper/sane_dev
> dmsetup remove sane_dev
> start_sector=$((204800-2053-1))
> echo $'0 2053 linear /dev/loop0 0\n2053 1 error\n2054 '"${start_sector} linear /dev/loop0 2054" | 
>   dmsetup create error_dev
> mount -t ext2 /dev/mapper/error_dev /some/where
> cat /some/where/unreadable_file # 3rd sector of file is unreadable
cat: /some/where/unreadable_file: Input/output error

Debo admitir que estoy un poco confundido porque no he logrado leer sectores individuales de ese archivo sin un error (con dd .. seek=...). Quizás sea un problema de lectura anticipada.

Puede usar CharybdeFS que fue hecho exactamente para este tipo de propósito.

Es un sistema de archivos de fusibles pasivo como PetardFS pero mucho más configurable.

Vea el libro de cocina CharybdeFS aquí: http://www.scylladb.com/2016/05/02/fault-injection-filesystem-cookbook/

Es lo suficientemente avanzado como para probar una base de datos.