Reduzca los tiempos de reintento / espera de bloque incorrecto en Ubuntu


10

¿Cómo puedo reducir el tiempo de espera IO y los tiempos de reintento para que el sistema operativo no intente escribir continuamente en una unidad que falla?

Tengo un sistema que utilizo para hacer copias de contenido de demostración que se presta a los clientes en discos duros de escritorio SATA normales. Conectamos muchas unidades a la vez a través de SAS y copiamos contenido a ellas mediante un script.

Debido a que las unidades se prestan, ocasionalmente algunas vuelven dañadas pero no sé si están dañadas, por lo que la próxima vez que la unidad se reutilice en una operación de copia, ralentiza otras unidades a medida que el sistema reintenta IO a esa unidad. A veces pueden pasar horas antes de que note el disco defectuoso y lo elimine. Después de retirar la unidad, el resto de las unidades comienzan a escribir a velocidad normal.

No me importa recuperar los discos duros. Solo necesito eliminarlos para que no ralenticen todo lo demás.

También estoy investigando badblocks y smartmontools y estoy considerando escribir una verificación previa en las unidades antes de comenzar a escribir.

SO: Ubuntu Linux (12.04 lts)


¿Qué hay de malo en verificar los datos SMART a través de udisks/ smartmonctl? Un problema clásico de XY aquí, creo.
Deer Hunter

2
Gracias, investigaré más sobre smartmonctl. En mi experiencia, si los sectores defectuosos ocurrieron durante el último envío, el estado INTELIGENTE muestra que la unidad sigue siendo buena, y funciona bien hasta que se produce una parte aleatoria durante la copia, y luego se ralentiza, lo que también afecta a otras unidades hasta Se quita.
Ryan Sorensen

La pregunta no ha recibido una respuesta directa, por lo que no sabemos si es posible en Linux: ¿cómo puedo reducir el tiempo de espera IO y los tiempos de reintento?
imz - Ivan Zakharyaschev

@ imz - IvanZakharyaschev unix.stackexchange.com/a/147304/25985 Sin embargo, el núcleo registra estos errores, por lo que si todo lo que quiere hacer es detectar un disco defectuoso antes de que se convierta en un problema, puede escanear los registros del sistema en intervalos regulares.
Ricitos

@gol ¿Qué pasa si quiero atraparlo más rápido? Sin esperar, Dios sabe cuánto tiempo antes de que la operación IO desbloquee la notificación de un error. (En realidad, estoy tratando de guardar los datos de un disco con errores, pero mi problema es similar: encontrarse con estos sectores "erróneos" causa grandes retrasos ... Quizás también podría seguir los consejos e inventar una forma de alimente la información de la prueba SMART para ddrescueque ni siquiera toque los sectores informados por SMART.)
imz - Ivan Zakharyaschev

Respuestas:


7

No he usado este sintonizable antes, pero probablemente desee ajustar el eh_timeout (tiempo de espera de manejo de errores) para la unidad en cuestión:

[root@localhost device]# cat /sys/block/sda/device/eh_timeout
10
[root@localhost device]# 

Lo anterior muestra sdaestablecido en 10 segundos. De la base de conocimiento de Red Hat:

En ciertas configuraciones de almacenamiento (por ejemplo, configuraciones con muchos LUN), el código de manejo de errores SCSI puede pasar una gran cantidad de tiempo emitiendo comandos como TEST UNIT READY a dispositivos de almacenamiento que no responden. Se ha agregado un nuevo parámetro sysfs, eh_timeout, al objeto del dispositivo SCSI, que permite la configuración del valor de tiempo de espera para los comandos TEST UNIT READY y REQUEST SENSE utilizados por el código de manejo de errores SCSI. Esto disminuye la cantidad de tiempo dedicado a verificar estos dispositivos que no responden. El valor predeterminado de eh_timeout es 10 segundos, que era el valor de tiempo de espera utilizado antes de agregar esta funcionalidad.


Estoy revisando esto ahora. Ubuntu no tiene un eh_timeout, pero tiene un archivo de tiempo de espera que puede ser lo mismo. El valor predeterminado de Ubuntu parece ser de 30 segundos. Lo reducirá a 5 segundos e informará.
Ryan Sorensen

1
Por curiosidad, ¿cuál fue su resultado?
Bratchley

Establecer el indicador de tiempo de espera en 12.04 no parecía hacer nada. Estoy planeando actualizar un sistema de prueba a 14.04 este fin de semana porque tiene eh_timeout (y también timeout).
Ryan Sorensen

@RyanSorensen, ¿tuvo la oportunidad de ver si este parámetro funciona alguna vez?
Nat

No pude modificar, eh_timeoutpero pude cambiar timeoutpara lograr la tarea en cuestión.
GuitarPicker

2

Controle /sys/block/<dev>/statlos dispositivos que le interesan y compare el décimo parámetro (io_ticks).

p.ej, ticks = io_ticks - prev_ticks / seconds_deltatime / 10

Este es el porcentaje de tiempo disponible que el disco ha pasado esperando el disco io.

Vale la pena verificar cerca del 100%, por supuesto, o de lo contrario, sea realmente inteligente y compárelo con el promedio de todos sus discos y seleccione en cualquier disco (s) por encima de la media.

Consulte la documentación de estadísticas de la capa de bloques .

De lo contrario, usa algo como Munin y grafica. Puede hacer que Munin le avise si supera un umbral, por ejemplo, 90% o lo que muestre su gráfica es una buena cifra de alerta.

por ejemplo, vea estos dos gráficos de Munin que muestran que / dev / sdi necesita analizarse. En este ejemplo, si / dev / sdi es parte de una matriz, toda la matriz sufriría por ello.

Utilización de disco por dispositivo: por día

Utilización de disco por dispositivo: por semana

Si observa el gráfico de la semana, verá que / dev / sdc también podría ser lento.

Debo agregar que / dev / sdi arriba no está roto, es solo un disco lento (en realidad un disco verde que alguien agregó a una matriz de discos sata de grado empresarial) que desaceleró la matriz. Un disco con falla real sobresaldría como un pulgar dolorido.

En resumen, probablemente usaría un script si tuviera tiempo, pero Munin si solo quisiera una solución rápida y conectarme al servidor fue fácil.


¡Gracias! La información sobre las estadísticas de io en Linux es realmente nueva y parece ser útil (para mí) en tales situaciones.
imz - Ivan Zakharyaschev
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.