Por que o ZFS não está fazendo nada com o setor duff do meu disco?

Question

Fiquei com a impressão de que, se ocorrer um erro de E / S durante uma leitura de um pool do ZFS, duas coisas acontecerão:

1. A falha será registrada na estatística READ ou CKSUM do dispositivo relevante, propagando-se para cima em direção ao nível do pool.
2. • Dados redundantes serão usados para reconstruir o bloco solicitado, retornar o bloco solicitado para o chamador e, se a unidade duff ainda estiver funcional, reescrever o bloco para ele, OR
   • Um erro de E / S será retornado se os dados redundantes não estiverem disponíveis para corrigir o erro de leitura.

Parece que um dos discos na minha configuração de espelho desenvolveu um setor ruim. Isso por si só não é alarmante; essas coisas acontecem e é exatamente por isso que tenho redundância (um espelho bidirecional, para ser exato). Toda vez que eu esfrego a piscina ou leio os arquivos em um determinado diretório (eu não me incomodei ainda para determinar exatamente qual arquivo é a culpa), o seguinte aparece no dmesg, obviamente com diferentes timestamps:

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 é um Debian Wheezy bastante atualizado, kernel 3.2.0-4-amd64 # 1 SMP Debian 3.2.63-2 x86_64, ZoL 0.6.3. Versões do pacote são atuais em 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. O único pacote que fixa que eu é de conhecimento para ZoL, para o qual eu tenho (como previsto pelo zfsonlinux pacote):

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

Executando hdparm -R nos relatórios da unidade em que o Write-Read-Verify é ligado (isso é um Seagate, então tem esse recurso e eu usá-lo como um rede extra de segurança; a latência de gravação adicional não é um problema meu padrão de uso interativo é muito pesado para leitura):

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

Mesmo com a indicação clara de que algo está errado, zpool status afirma que não há problema com o 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

Esse erro tem aparecido nos logs regularmente pela última vez vários dias agora (desde 27 de outubro), então eu não estou muito inclinado a escrever como um mero acaso. Eu corro os discos com SCTERC bem curto timeouts; 1,5 segundos de leitura (para recuperar rapidamente de erros de leitura), 10 segundos de gravação. Confirmei que esses valores estão ativos no dirigir em questão.

O smartd continua me importunando (o que em si é uma coisa boa!) sobre o fato de que a contagem de erros do 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.

Executar smartctl --attributes na unidade em questão produz o seguinte:

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 gritante fora do comum lá. Note que esta é uma unidade empresarial, portanto, cinco anos de garantia e classificados para 24x7 operação (o que significa que é para ser confiável por mais de 40.000 horas de operação, em comparação com o pouco menos de 10.000 horas sob o seu cinto de modo longe). Observe o número 5 no atributo 187 Reported_Uncorrect; isso é onde está o problema. Observe também o relativamente baixo Start_Stop_Count e Valores de Power_Cycle_Count abaixo de 100 cada.

Não que eu ache relevante neste caso, mas sim, o sistema não tem RAM ECC.

Propriedades não padrão do sistema de arquivos raiz no pool são:

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 correspondentemente para o próprio pool :

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

Essas listas foram obtidas executando {zfs,zpool} get all akita | grep -v default .

Agora, as perguntas:

1. Por que o ZFS não reporta nada sobre o problema de leitura? Está claramente se recuperando dele.

2. Por que o ZFS não está reescrevendo automaticamente o setor duff que o unidade está claramente tendo problemas para ler, por sua vez, esperamos que desencadeando uma realocação pelo inversor, dado que existe redundância para reparo automático no caminho da solicitação de leitura?

Answer 1

Eu suspeito que o driver ATA está tentando novamente a operação de leitura algumas vezes quando recebe um erro antes de passar o erro de volta ao driver do sistema de arquivos.

O que isso significa é que, quando o driver do sistema de arquivos ZFS recebe o resultado da leitura, os dados estão todos lá e corretos, mas provavelmente demorou um pouco mais do que o normal para acontecer. Obviamente, não há contador de erros para uma latência acima da média, portanto, nada é registrado.

O fato de que o valor SMART para Reported_Uncorrect não é 0 me faz suspeitar que a causa da falha é o disco em si, ao contrário de dizer que o cabo SATA ou o controlador SATA está sendo flakey.

Se esse for o caso, provavelmente o disco acabará morrendo mais e começará a falhar, mesmo depois de quantas tentativas o driver de dispositivo de bloco estiver tentando. Como tal, meu conselho seria substituir o disco.

Acionar um teste SMART longo provavelmente falharia nos blocos afetados, se você quisesse fazer com que o erro desaparecesse, reescrever esses blocos (com dd, por exemplo) deve fazer com que o disco troque esses setores, mas na minha experiência já foi uma unidade começa a ir é melhor apenas substituí-lo e ser feito com ele.

    

Answer 2

Eu tinha um disco SCSI inválido com um ataque do ZFS no Solaris. Eu estava varrendo os arquivos de log para obter informações sobre mensagens de erro para coletar provas de que o disco estava ruim e fazer com que o Oracle o cobrisse sobre a manutenção do hardware. Eu corri grep para certas seqüências de caracteres em logs de erro e essas linhas mostrando erros de disco seria na minha tela do console. Quando o "Explorer" (a ferramenta de log e relatório do sistema para Solaris) foi executado e enviado para o Oracle, eles disseram que não havia erros nos discos. Mas eu os tive no meu histórico de tela. Eu verifiquei e foi realmente ido dos logs no disco.

Aqui está o que estava acontecendo ... O ZFS promete zero erros no sistema de arquivos, e não zero erros de dados. Quando uma corrupção séria é encontrada, ela reverte a transação, fazendo o que for necessário para tornar a integridade do sistema de arquivos boa. Como resultado, as atualizações de arquivos são perdidas quando são revertidas para uma versão anterior do arquivo antes da corrupção e, portanto, a perda de dados pode ocorrer. Mas o seu sistema de arquivos está livre de erros.

Talvez por erros simples, o ZFS possa reverter e reescrever os dados em outra tentativa, mas parece que, em casos sérios de comportamento ruim do disco, ele pode entrar em uma armadilha onde os dados não estão sendo recuperados e gravados. Se você precisar coletar evidências sobre erros de disco, faça-os aparecer na tela e não confie na prova que residirá no disco, onde os dados estão potencialmente sendo redefinidos pelas reversões de transação do ZFS.