Warum macht ZFS nichts mit dem Duff-Sektor meiner Festplatte?

Ich hatte den Eindruck, dass zwei Dinge passieren werden, wenn beim Lesen aus einem ZFS-Pool ein E / A-Fehler auftritt:

1. Der Fehler wird entweder in der READ- oder der CKSUM-Statistik des jeweiligen Geräts aufgezeichnet und breitet sich nach oben in Richtung Poolebene aus.
2. • Redundante Daten werden verwendet, um den angeforderten Block zu rekonstruieren, den angeforderten Block an den Aufrufer zurückzugeben und, wenn das Duff-Laufwerk noch funktionsfähig ist, den Block neu zu schreiben, ODER
   • Ein E / A-Fehler wird zurückgegeben, wenn keine redundanten Daten verfügbar sind, um den Lesefehler zu korrigieren.

Es scheint, dass eine der Festplatten in meinem Spiegel-Setup einen fehlerhaften Sektor entwickelt hat. Das allein ist nicht alarmierend; Solche Dinge passieren, und genau deshalb habe ich Redundanz (ein Zwei-Wege-Spiegel, um genau zu sein). Jedes Mal, wenn ich den Pool bereinige oder die Dateien in einem bestimmten Verzeichnis durchlese (ich habe mich noch nicht darum gekümmert, genau festzustellen, welche Datei fehlerhaft ist), wird in dmesg Folgendes angezeigt, offensichtlich mit unterschiedlichen Zeitstempeln:

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

Dies ist ein ziemlich aktuelles Debian Wheezy, Kernel 3.2.0-4-amd64 # 1 SMP Debian 3.2.63-2 x86_64, ZoL 0.6.3. Paketversionen sind aktuell bei 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. Das einzige Paket, das mir bekannt ist, ist für ZoL, für das ich habe (wie vom zfsonlinux-Paket bereitgestellt):

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

Das Ausführen hdparm -Rauf dem Laufwerk meldet, dass Write-Read-Verify aktiviert ist (dies ist ein Seagate, verfügt also über diese Funktion und ich verwende sie als zusätzliches Sicherheitsnetz; die zusätzliche Schreiblatenz ist kein Problem, da mein interaktives Verwendungsmuster sehr gelesen ist -schwer):

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

Selbst angesichts des klaren Hinweises, dass etwas nicht stimmt, wird zpool statusbehauptet, dass es kein Problem mit dem Pool gibt:

  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

Dieser Fehler taucht seit einigen Tagen (seit dem 27. Oktober) regelmäßig in den Protokollen auf, sodass ich nicht besonders geneigt bin, ihn nur als Zufall abzuschreiben. Ich starte die Festplatten mit recht kurzen SCTERC-Timeouts. 1,5 Sekunden Lesen (um sich schnell von Lesefehlern zu erholen), 10 Sekunden Schreiben. Ich habe bestätigt, dass diese Werte auf dem betreffenden Laufwerk aktiv sind.

smartd belästigt mich immer wieder (was an sich schon gut ist!), dass die ATA-Fehlerzahl steigt:

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.

Das Ausführen smartctl --attributesauf dem betreffenden Laufwerk ergibt Folgendes:

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

Nichts Außergewöhnliches . Beachten Sie, dass es sich um ein Unternehmenslaufwerk handelt, also fünf Jahre Garantie und für den Betrieb rund um die Uhr ausgelegt (was bedeutet, dass es für mehr als 40.000 Betriebsstunden zuverlässig sein soll, verglichen mit den bisher knapp 10.000 Betriebsstunden). Beachten Sie die Nummer 5 im Attribut 187 Reported_Uncorrect; Dort liegt das Problem. Beachten Sie auch die relativ niedrigen Werte für Start_Stop_Count und Power_Cycle_Count von jeweils unter 100.

Nicht, dass ich denke, dass dies in diesem Fall relevant ist, aber ja, das System verfügt über ECC-RAM.

Nicht standardmäßige Eigenschaften des Root- Dateisystems im Pool sind:

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                    -

und entsprechend für den Pool selbst :

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

Diese Listen wurden durch Ausführen erhalten {zfs,zpool} get all akita | grep -v default.

Nun zu den Fragen:

1. Warum meldet ZFS nichts über das Leseproblem? Es erholt sich eindeutig davon.

2. Warum schreibt ZFS den Duff-Sektor nicht automatisch neu, sodass das Laufwerk eindeutig Probleme beim Lesen hat, was hoffentlich eine Verlagerung durch das Laufwerk auslöst, da eine ausreichende Redundanz für die automatische Reparatur im Leseanforderungspfad vorhanden ist?

Ich vermute, dass der ATA-Treiber den Lesevorgang einige Male wiederholt, wenn er einen Fehler empfängt, bevor er den Fehler an den Dateisystemtreiber zurückgibt.

Dies bedeutet, dass bis der ZFS-Dateisystemtreiber das Ergebnis des Lesens erhält, die Daten alle vorhanden und korrekt sind, aber es hat wahrscheinlich etwas länger als normal gedauert. Es gibt natürlich keinen Fehlerzähler für eine überdurchschnittliche Latenz, daher wird nichts protokolliert.

Die Tatsache, dass der SMART-Wert für Reported_Uncorrect nicht 0 ist, lässt mich vermuten, dass die Ursache des Fehlers die Festplatte selbst ist, im Gegensatz dazu, dass das SATA-Kabel oder der SATA-Controller flockig sind.

Wenn dies der Fall ist, stirbt die Festplatte höchstwahrscheinlich mehr und kann auch nach so vielen Wiederholungsversuchen, die der Blockgerätetreiber versucht, nicht mehr lesen. Als solches wäre mein Rat, die Festplatte zu ersetzen.

Das Auslösen eines langen SMART-Tests würde wahrscheinlich bei den betroffenen Blöcken fehlschlagen. Wenn Sie den Fehler beheben möchten, sollte das Umschreiben dieser Blöcke (z. B. mit dd) dazu führen, dass die Festplatte diese Sektoren austauscht. Meiner Erfahrung nach wird jedoch einmal ein Laufwerk gestartet Um zu gehen, ist es besser, es einfach zu ersetzen und damit fertig zu sein.

Ich hatte eine fehlerhafte SCSI-Festplatte mit einem ZFS-Raid unter Solaris. Ich habe die Protokolldateien nach Informationen zu Fehlermeldungen durchsucht, um den Beweis zu erbringen, dass die Festplatte fehlerhaft ist, und Oracle zu veranlassen, sie bei der Hardwarewartung zu behandeln. Ich habe grep für bestimmte Zeichenfolgen in Fehlerprotokollen ausgeführt, und diese Zeilen mit Festplattenfehlern befinden sich auf meinem Konsolenbildschirm. Als "Explorer" (das Systemprotokoll- und Berichterstellungstool für Solaris) ausgeführt und an Oracle gesendet wurde, gab es keine Fehler auf den Datenträgern. Aber ich hatte sie in meinem Bildschirmverlauf. Ich habe nachgesehen und es war tatsächlich aus den Protokollen auf der Festplatte verschwunden.

Hier ist, was los war ... ZFS verspricht null Dateisystemfehler, keine null Datenfehler. Wenn eine schwerwiegende Beschädigung auftritt, wird die Transaktion zurückgesetzt und alles getan, um die Integrität des Dateisystems zu verbessern. Infolgedessen gehen Dateiaktualisierungen verloren, wenn sie vor der Beschädigung auf eine frühere Version der Datei zurückgesetzt werden, und daher kann es zu Datenverlust kommen. Ihr Dateisystem ist jedoch fehlerfrei.

Möglicherweise kann ZFS bei einfachen Fehlern die Daten in einem anderen Versuch zurücksetzen und neu schreiben. In schwerwiegenden Fällen von schlechtem Festplattenverhalten scheint es jedoch zu einem Catch-22 zu kommen, bei dem Daten nicht wiederhergestellt und geschrieben werden. Wenn Sie Beweise für Festplattenfehler sammeln müssen, lassen Sie sie auf dem Bildschirm erscheinen und verlassen Sie sich nicht auf Beweise, die sich auf der Festplatte befinden, wo Daten möglicherweise durch ZFS-Transaktions-Rollbacks zurückgesetzt werden.