Perché ZFS non sta facendo nulla con il settore duff del mio disco?

Avevo l'impressione che se si verifica un errore I / O durante una lettura da un pool ZFS, accadranno due cose:

1. L'errore verrà registrato nella statistica READ o CKSUM del dispositivo in questione, propagandosi verso l'alto verso il livello del pool.
2. • I dati ridondanti verranno utilizzati per ricostruire il blocco richiesto, restituire il blocco richiesto al chiamante e se l'unità Duff è ancora funzionante riscrivere il blocco su di esso, OPPURE
   • Verrà restituito un errore I / O se non sono disponibili dati ridondanti per correggere l'errore di lettura.

Sembra che uno dei dischi nella mia configurazione del mirror abbia sviluppato un settore danneggiato. Questo da solo non è allarmante; succedono cose del genere ed è esattamente per questo che ho la ridondanza (uno specchio a due vie, per l'esattezza). Ogni volta che scrub il pool o leggo i file in una particolare directory (non mi sono ancora preoccupato di determinare esattamente quale file è in errore), appare in Dmesg, ovviamente con timestamp variabili:

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

Questo è un Debian Wheezy abbastanza aggiornato, kernel 3.2.0-4-amd64 # 1 SMP Debian 3.2.63-2 x86_64, ZoL 0.6.3. Le versioni del pacchetto sono aggiornate a 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. L'unico pacchetto che conosco è per ZoL, per il quale ho (come fornito dal pacchetto zfsonlinux):

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

L'esecuzione hdparm -Rsull'unità segnala che Write-Read-Verify è attivato (si tratta di Seagate, quindi ha quella funzione e la utilizzo come rete di sicurezza aggiuntiva; la latenza di scrittura aggiuntiva non è un problema poiché il mio modello di utilizzo interattivo è molto letto -pesante):

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

Anche data la chiara indicazione che qualcosa non va, zpool statusafferma che non c'è nessun problema con il pool:

  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

Questo errore è apparso regolarmente nei registri negli ultimi giorni (dal 27 ottobre), quindi non sono terribilmente incline a scriverlo come un semplice colpo di fortuna. Eseguo i dischi con timeout SCTERC piuttosto brevi; 1,5 secondi di lettura (per recuperare rapidamente da errori di lettura), 10 secondi di scrittura. Ho confermato che questi valori sono attivi sull'unità in questione.

smartd continua a infastidirmi (il che è di per sé una buona cosa!) sul fatto che il conteggio degli errori ATA sta salendo:

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'esecuzione smartctl --attributessull'unità in questione produce quanto segue:

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

Niente di eclatante fuori dall'ordinario lì. Si noti che si tratta di un disco aziendale, quindi cinque anni di garanzia e valutato per il funzionamento 24x7 (il che significa che è pensato per essere affidabile per oltre 40.000 ore di funzionamento, rispetto alle poco meno di 10.000 ore finora sotto la cintura). Notare il numero 5 nell'attributo 187 Reported_Uncorrect; ecco dove si trova il problema. Nota anche i valori Start_Stop_Count e Power_Cycle_Count abbastanza bassi di meno di 100 ciascuno.

Non che penso sia rilevante in questo caso, ma sì, il sistema ha RAM ECC.

Le proprietà non predefinite del file system radice sul pool sono:

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                    -

e corrispondentemente per il pool stesso :

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

Questi elenchi sono stati ottenuti eseguendo {zfs,zpool} get all akita | grep -v default.

Ora per le domande:

1. Perché ZFS non segnala nulla sul problema di lettura? Si sta chiaramente riprendendo.

2. Perché ZFS non sta riscrivendo automaticamente il settore duff che l'unità ha chiaramente problemi a leggere, a sua volta si spera innescando una delocalizzazione da parte dell'unità, dato che esiste una ridondanza sufficiente per la riparazione automatica nel percorso della richiesta di lettura?

Sospetto che il driver ATA stia ripetendo l'operazione di lettura un paio di volte quando riceve un errore prima di restituire l'errore al driver del filesystem.

Ciò significa che quando il driver del filesystem ZFS ottiene il risultato della lettura, i dati sono tutti lì, e corretti, ma probabilmente ci è voluto un po 'più del normale per accadere. Ovviamente non esiste un contatore di errori per una latenza superiore alla media, quindi non è stato registrato nulla.

Il fatto che il valore SMART per Reported_Uncorrect non sia 0 mi fa sospettare che la causa dell'errore sia il disco stesso, al contrario di dire che il cavo SATA o il controller SATA sono flakey.

In questo caso, molto probabilmente il disco alla fine morirà di più e inizierà a non leggere anche dopo molti tentativi che il driver del dispositivo a blocchi sta tentando. Pertanto, il mio consiglio sarebbe di sostituire il disco.

Triggerare un lungo test SMART probabilmente fallirebbe sui blocchi interessati, se si volesse far scomparire l'errore riscrivendo quei blocchi (con dd per esempio) si dovrebbe far sì che il disco si scambiasse quei settori, ma nella mia esperienza è una volta che si avvia un'unità per andare è meglio semplicemente sostituirlo ed essere fatto con esso.

Ho avuto un cattivo disco SCSI con un raid ZFS su Solaris. Stavo scansionando i file di registro per informazioni sui messaggi di errore per raccogliere prove che il disco era danneggiato e convincere Oracle a coprirlo durante la manutenzione dell'hardware. Ho eseguito grep per alcune stringhe nei log degli errori e queste righe che mostrano gli errori del disco sarebbero nella schermata della mia console. Quando "Explorer" (il registro di sistema e lo strumento di reporting per Solaris) veniva eseguito e inviato a Oracle, dicevano che non c'erano errori sui dischi. Ma li avevo nella mia cronologia dello schermo. Ho controllato ed era effettivamente andato dai registri sul disco.

Ecco cosa stava succedendo ... ZFS promette zero errori nel file system, non zero errori nei dati. Quando si verifica un danneggiamento grave, ripristina la transazione, facendo tutto il necessario per rendere valida l'integrità del file system. Di conseguenza, gli aggiornamenti dei file vengono persi quando si esegue il rollback a una versione precedente del file prima della corruzione e pertanto potrebbero verificarsi perdite di dati. Ma il tuo file system è privo di errori.

Forse per semplici errori, ZFS può eseguire il rollback e riscrivere i dati in un altro tentativo, ma sembra in casi gravi di cattivo comportamento del disco, può entrare in un catch-22 in cui i dati non vengono recuperati e scritti. Se è necessario raccogliere prove sugli errori del disco, farli apparire sullo schermo e non fare affidamento sulla prova che risiederà sul disco, dove i dati potrebbero essere ripristinati dai rollback delle transazioni ZFS.