Pourquoi ZFS ne fait rien avec le secteur duff de mon disque?

J'avais l'impression que si une erreur d'E / S se produit lors d'une lecture à partir d'un pool ZFS, deux choses se produiront:

1. L'échec sera enregistré dans la statistique READ ou CKSUM du périphérique concerné, se propageant vers le haut vers le niveau du pool.
2. • Les données redondantes seront utilisées pour reconstruire le bloc demandé, retourner le bloc demandé à l'appelant et si le lecteur duff est toujours fonctionnel, réécrire le bloc, OU
   • Une erreur d'E / S sera renvoyée si des données redondantes ne sont pas disponibles pour corriger l'erreur de lecture.

Il semble que l'un des disques de ma configuration miroir ait développé un mauvais secteur. Cela en soi n'est pas alarmant; de telles choses se produisent, et c'est exactement pourquoi j'ai une redondance (un miroir bidirectionnel, pour être exact). Chaque fois que je nettoie le pool ou que je lis les fichiers dans un répertoire particulier (je n'ai pas encore pris la peine de déterminer exactement quel fichier est en cause), ce qui suit apparaît dans dmesg, évidemment avec des horodatages 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

Il s'agit d'un Debian Wheezy assez récent, du noyau 3.2.0-4-amd64 # 1 SMP Debian 3.2.63-2 x86_64, ZoL 0.6.3. Les versions des paquets sont à jour à 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. Le seul package épinglé que je connaisse est pour ZoL, pour lequel j'ai (comme fourni par le package zfsonlinux):

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

L'exécution hdparm -Rsur le lecteur signale que Write-Read-Verify est activé (il s'agit d'un Seagate, donc cette fonctionnalité et je l'utilise comme un filet de sécurité supplémentaire; la latence d'écriture supplémentaire n'est pas un problème puisque mon modèle d'utilisation interactive est très lu -lourd):

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

Même étant donné l'indication claire que quelque chose ne va pas, zpool statusaffirme qu'il n'y a pas de problème avec la piscine:

  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

Cette erreur apparaît régulièrement dans les journaux depuis plusieurs jours maintenant (depuis le 27 octobre), donc je ne suis pas très enclin à l'écrire comme un simple coup de chance. J'exécute les disques avec des délais d'expiration SCTERC assez courts; 1,5 secondes de lecture (pour récupérer rapidement des erreurs de lecture), 10 secondes d'écriture. J'ai confirmé que ces valeurs sont actives sur le lecteur en question.

smartd n'arrête pas de me harceler (ce qui est en soi une bonne chose!) sur le fait que le nombre d'erreurs ATA grimpe:

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.

L'exécution smartctl --attributessur le lecteur en question donne les résultats suivants:

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

Rien ne saute hors de l'ordinaire là. Notez qu'il s'agit d'un lecteur d'entreprise, donc cinq ans de garantie et évalué pour un fonctionnement 24x7 (ce qui signifie qu'il est censé être fiable pour plus de 40000 heures de fonctionnement, contre un peu moins de 10000 heures à ce jour). Notez le nombre 5 dans l'attribut 187 Reported_Uncorrect; c'est là que réside le problème. Notez également les valeurs assez faibles Start_Stop_Count et Power_Cycle_Count inférieures à 100 chacune.

Non pas que je pense que c'est pertinent dans ce cas, mais oui, le système a une RAM ECC.

Les propriétés non par défaut du système de fichiers racine sur le pool sont:

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                    -

et en conséquence pour la piscine elle - même :

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

Ces listes ont été obtenues en exécutant {zfs,zpool} get all akita | grep -v default.

Maintenant pour les questions:

1. Pourquoi ZFS ne rapporte-t-il rien sur le problème de lecture? Il s'en remet clairement.

2. Pourquoi ZFS ne réécrit-il pas automatiquement le secteur duff que le lecteur a clairement du mal à lire, ce qui, espérons-le, déclenche une relocalisation par le lecteur, étant donné qu'il existe une redondance suffisante pour la réparation automatique dans le chemin de demande de lecture?

Je soupçonne que le pilote ATA relance l'opération de lecture plusieurs fois lorsqu'il reçoit une erreur avant de la renvoyer au pilote du système de fichiers.

Cela signifie qu'au moment où le pilote du système de fichiers ZFS obtient le résultat de la lecture, les données sont toutes là et correctes, mais cela a probablement pris un peu plus de temps que la normale. Il n'y a bien sûr pas de compteur d'erreurs pour une latence supérieure à la moyenne, donc rien n'est enregistré.

Le fait que la valeur SMART pour Reported_Uncorrect n'est pas 0 me fait soupçonner que la cause de l'échec est le disque lui-même, par opposition à dire que le câble SATA ou le contrôleur SATA est floconneux.

Si tel est le cas, il est fort probable que le disque finira par mourir davantage et commencera à ne pas lire, même après de nombreuses tentatives du pilote de périphérique de bloc. En tant que tel, mon conseil serait de remplacer le disque.

Déclencher un long test SMART échouerait probablement sur les blocs affectés, si vous vouliez que l'erreur disparaisse, la réécriture de ces blocs (avec dd par exemple) devrait entraîner la permutation du disque sur ces secteurs, mais d'après mon expérience, une fois qu'un lecteur démarre pour y aller, il vaut mieux simplement le remplacer et en finir avec.

J'ai eu un mauvais disque SCSI avec un raid ZFS sur Solaris. J'analysais les fichiers journaux pour obtenir des informations sur les messages d'erreur afin de recueillir la preuve que le disque était défectueux et de demander à Oracle de le couvrir lors de la maintenance du matériel. J'ai exécuté grep pour certaines chaînes dans les journaux d'erreurs et ces lignes montrant des erreurs de disque se trouveraient dans l'écran de ma console. Lorsque "Explorer" (le journal système et l'outil de génération de rapports pour Solaris) a été exécuté et envoyé à Oracle, ils ont déclaré qu'il n'y avait aucune erreur sur les disques. Mais je les avais sur mon historique d'écran. J'ai vérifié et c'était effectivement parti des journaux sur le disque.

Voici ce qui se passait ... ZFS promet zéro erreur de système de fichiers, pas zéro erreur de données. Lorsqu'une corruption grave est rencontrée, elle annule la transaction, faisant tout ce qui est nécessaire pour améliorer l'intégrité du système de fichiers. Par conséquent, les mises à jour de fichiers sont perdues lorsqu’il revient à une version antérieure du fichier avant la corruption, et par conséquent une perte de données peut se produire. Mais votre système de fichiers est exempt d'erreurs.

Peut-être que pour des erreurs simples, ZFS peut restaurer et réécrire les données dans une autre tentative, mais il semble que dans les cas graves de mauvais comportement du disque, il puisse entrer dans un catch-22 où les données ne sont pas récupérées et écrites. Si vous avez besoin de collecter des preuves sur des erreurs de disque, faites-les apparaître à l'écran et ne vous fiez pas à une preuve qui résidera sur le disque, où les données sont potentiellement réinitialisées par des restaurations de transactions ZFS.