¿Por qué ZFS no está haciendo nada con el sector duff de mi disco?

Tenía la impresión de que si se produce un error de E / S durante una lectura de un grupo de ZFS, sucederán dos cosas:

1. La falla se registrará en la estadística READ o CKSUM del dispositivo relevante, propagándose hacia arriba hacia el nivel del grupo.
2. • Los datos redundantes se utilizarán para reconstruir el bloque solicitado, devolver el bloque solicitado a la persona que llama y, si la unidad duff sigue funcionando, reescribir el bloque, O
   • Se devolverá un error de E / S si no hay datos redundantes disponibles para corregir el error de lectura.

Parece que uno de los discos en mi configuración de espejo ha desarrollado un sector defectuoso. Eso por sí mismo no es alarmante; tales cosas suceden, y es exactamente por eso que tengo redundancia (un espejo de dos vías, para ser exactos). Cada vez que friego el grupo o leo los archivos en un directorio particular (no me he molestado aún en determinar exactamente qué archivo tiene la culpa), aparece lo siguiente en dmesg, obviamente con marcas de tiempo variables:

Nov  1 09:54:26 yeono kernel: [302621.236549] ata6.00: exception Emask 0x0 SAct 0x9c10 SErr 0x0 action 0x0
Nov  1 09:54:26 yeono kernel: [302621.236557] ata6.00: irq_stat 0x40000008
Nov  1 09:54:26 yeono kernel: [302621.236566] ata6.00: failed command: READ FPDMA QUEUED
Nov  1 09:54:26 yeono kernel: [302621.236578] ata6.00: cmd 60/a8:78:18:5a:12/00:00:5c:01:00/40 tag 15 ncq 86016 in
Nov  1 09:54:26 yeono kernel: [302621.236580]          res 41/40:a8:18:5a:12/00:00:5c:01:00/00 Emask 0x409 (media error) <F>
Nov  1 09:54:26 yeono kernel: [302621.236585] ata6.00: status: { DRDY ERR }
Nov  1 09:54:26 yeono kernel: [302621.236589] ata6.00: error: { UNC }
Nov  1 09:54:26 yeono kernel: [302621.238214] ata6.00: configured for UDMA/133

Este es un Debian Wheezy bastante actualizado, kernel 3.2.0-4-amd64 # 1 SMP Debian 3.2.63-2 x86_64, ZoL 0.6.3. Las versiones del paquete son actuales en debian-zfs = 7 ~ wheezy, libzfs2 = 0.6.3-1 ~ wheezy, zfs-dkms = 0.6.3-1 ~ wheezy, zfs-initramfs = 0.6.3-1 ~ wheezy, zfsutils = 0.6 .3-1 ~ wheezy, zfsonlinux = 3 ~ wheezy, linux-image-amd64 = 3.2 + 46, linux-image-3.2.0-4-amd64 = 3.2.63-2. El único paquete de fijación que conozco es para ZoL, para el cual tengo (según lo dispuesto por el paquete zfsonlinux):

Package: *
Pin: release o=archive.zfsonlinux.org
Pin-Priority: 1001

La ejecución hdparm -Ren la unidad informa que Write-Read-Verify está activado (este es un Seagate, por lo que tiene esa característica y la uso como una red de seguridad adicional; la latencia de escritura adicional no es un problema ya que mi patrón de uso interactivo es muy leído -pesado):

/dev/disk/by-id/ata-ST4000NM0033-9ZM170_XXXXXXXX:
 write-read-verify =  2

Incluso dada la clara indicación de que algo anda mal, zpool statusafirma que no hay problema con el grupo:

  pool: akita
 state: ONLINE
  scan: scrub repaired 0 in 8h16m with 0 errors on Sat Nov  1 10:46:03 2014
config:

        NAME                        STATE     READ WRITE CKSUM
        akita                       ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            wwn-0x5000c50065e8414a  ONLINE       0     0     0
            wwn-0x5000c500645b0fec  ONLINE       0     0     0

errors: No known data errors

Este error ha estado apareciendo regularmente en los registros durante los últimos días (desde el 27 de octubre), por lo que no estoy terriblemente inclinado a descartarlo como una casualidad. Ejecuto los discos con tiempos de espera SCTERC bastante cortos; 1.5 segundos de lectura (para recuperarse rápidamente de los errores de lectura), 10 segundos de escritura. He confirmado que estos valores están activos en la unidad en cuestión.

smartd sigue molestándome (¡lo que en sí mismo es algo bueno!) sobre el hecho de que el conteo de errores de ATA está aumentando:

The following warning/error was logged by the smartd daemon:

Device: /dev/disk/by-id/ata-ST4000NM0033-9ZM170_XXXXXXXX [SAT], ATA error count increased from 4 to 5

For details see host's SYSLOG.

Ejecutar smartctl --attributesen la unidad en cuestión produce lo siguiente:

smartctl 5.41 2011-06-09 r3365 [x86_64-linux-3.2.0-4-amd64] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   076   063   044    Pre-fail  Always       -       48910012
  3 Spin_Up_Time            0x0003   091   091   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       97
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   092   060   030    Pre-fail  Always       -       1698336160
  9 Power_On_Hours          0x0032   089   089   000    Old_age   Always       -       9887
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       98
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   095   095   000    Old_age   Always       -       5
188 Command_Timeout         0x0032   100   099   000    Old_age   Always       -       10
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   058   052   045    Old_age   Always       -       42 (Min/Max 20/45)
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       61
193 Load_Cycle_Count        0x0032   100   100   000    Old_age   Always       -       492
194 Temperature_Celsius     0x0022   042   048   000    Old_age   Always       -       42 (0 11 0 0)
195 Hardware_ECC_Recovered  0x001a   052   008   000    Old_age   Always       -       48910012
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0

Nada deslumbrantemente fuera de lo común allí. Tenga en cuenta que esta es una unidad empresarial, por lo que tiene cinco años de garantía y está clasificada para funcionar las 24 horas del día, los 7 días de la semana (lo que significa que debe ser confiable durante más de 40,000 horas de operación, en comparación con las poco menos de 10,000 horas hasta ahora). Observe el número 5 en el atributo 187 Reported_Uncorrect; ahí es donde está el problema. También tenga en cuenta los valores bastante bajos de Start_Stop_Count y Power_Cycle_Count de menos de 100 cada uno.

No es que piense que es relevante en este caso, pero sí, el sistema tiene RAM ECC.

Las propiedades no predeterminadas del sistema de archivos raíz en el grupo son:

NAME   PROPERTY              VALUE                  SOURCE
akita  type                  filesystem             -
akita  creation              Thu Sep 12 18:03 2013  -
akita  used                  3,14T                  -
akita  available             434G                   -
akita  referenced            136K                   -
akita  compressratio         1.04x                  -
akita  mounted               no                     -
akita  mountpoint            none                   local
akita  version               5                      -
akita  utf8only              off                    -
akita  normalization         none                   -
akita  casesensitivity       sensitive              -
akita  usedbysnapshots       0                      -
akita  usedbydataset         136K                   -
akita  usedbychildren        3,14T                  -
akita  usedbyrefreservation  0                      -
akita  sync                  standard               local
akita  refcompressratio      1.00x                  -
akita  written               0                      -
akita  logicalused           2,32T                  -
akita  logicalreferenced     15K                    -

y correspondientemente para el grupo en sí :

NAME   PROPERTY               VALUE                  SOURCE
akita  size                   3,62T                  -
akita  capacity               62%                    -
akita  health                 ONLINE                 -
akita  dedupratio             1.00x                  -
akita  free                   1,36T                  -
akita  allocated              2,27T                  -
akita  readonly               off                    -
akita  ashift                 12                     local
akita  expandsize             0                      -
akita  feature@async_destroy  enabled                local
akita  feature@empty_bpobj    active                 local
akita  feature@lz4_compress   active                 local

Estas listas se obtuvieron mediante la ejecución {zfs,zpool} get all akita | grep -v default.

Ahora para las preguntas:

1. ¿Por qué ZFS no informa nada sobre el problema de lectura? Claramente se está recuperando de eso.

2. ¿Por qué ZFS no está reescribiendo automáticamente el sector duff de que la unidad está claramente teniendo problemas para leer, lo que a su vez desencadena una reubicación por parte de la unidad, dado que existe suficiente redundancia para la reparación automática en la ruta de solicitud de lectura?

Sospecho que el controlador ATA está volviendo a intentar la operación de lectura un par de veces cuando recibe un error antes de devolver el error al controlador del sistema de archivos.

Lo que esto significa es que cuando el controlador del sistema de archivos ZFS obtiene el resultado de la lectura, los datos están allí y son correctos, pero es probable que haya pasado un poco más de lo normal. Por supuesto, no hay un contador de errores para una latencia superior al promedio, por lo que no se registra nada.

El hecho de que el valor SMART para Reported_Uncorrect no sea 0 me hace sospechar que la causa de la falla es el disco en sí, en lugar de decir que el cable SATA o el controlador SATA son defectuosos.

Si este es el caso, lo más probable es que el disco finalmente muera más y comience a fallar en la lectura, incluso después de los muchos intentos que el controlador del dispositivo de bloque está intentando. Como tal, mi consejo sería reemplazar el disco.

Activar una prueba SMART larga probablemente fallaría en los bloques afectados, si desea que el error desaparezca, volver a escribir esos bloques (con dd, por ejemplo) debería hacer que el disco intercambie esos sectores, pero en mi experiencia es una vez que se inicia una unidad para ir, es mejor simplemente reemplazarlo y acabar de una vez.

Tenía un disco SCSI defectuoso con una incursión ZFS en Solaris. Estaba escaneando los archivos de registro para obtener información sobre los mensajes de error para reunir pruebas de que el disco estaba dañado y obtener Oracle para cubrirlo en el mantenimiento del hardware. Ejecuté grep para ciertas cadenas en los registros de errores y estas líneas que muestran errores de disco estarían en la pantalla de mi consola. Cuando se ejecutó "Explorer" (el registro del sistema y la herramienta de informes para Solaris) y se envió a Oracle, dijeron que no había errores en los discos. Pero los tenía en mi historial de pantalla. Lo comprobé y, de hecho, desapareció de los registros en el disco.

Esto es lo que estaba sucediendo ... ZFS promete cero errores en el sistema de archivos, no cero errores en los datos. Cuando se encuentra una corrupción grave, revierte la transacción, haciendo lo que sea necesario para mejorar la integridad del sistema de archivos. Como resultado, las actualizaciones de archivos se pierden cuando se revierte a una versión anterior del archivo antes de la corrupción y, por lo tanto, puede producirse la pérdida de datos. Pero su sistema de archivos está libre de errores.

Quizás por errores simples, ZFS puede revertir y reescribir los datos en otro intento, pero parece que en casos graves de mal comportamiento del disco, puede entrar en un catch-22 donde los datos no se recuperan y escriben. Si necesita reunir evidencia sobre errores de disco, haga que aparezcan en la pantalla y no confíe en la prueba que residirá en el disco, donde los retrocesos de transacciones de ZFS pueden restablecer los datos.