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

Tive 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 ao chamador e, se a unidade de duff ainda estiver funcional, reescreva o bloco para ele, OU
   • Um erro de E / S será retornado se 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 defeituoso. Isso por si só não é alarmante; essas coisas acontecem, e é exatamente por isso que tenho redundância (um espelho de mão dupla, para ser exato). Toda vez que limpo o pool ou leio os arquivos em um diretório específico (ainda não me preocupo em determinar exatamente qual arquivo está com defeito), o seguinte é exibido no dmesg, obviamente com carimbos de data e hora variados:

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 SMP Debian Wheezy bastante atualizado, do kernel 3.2.0-4-amd64 # 1 Debian 3.2.63-2 x86_64, ZoL 0.6.3. As versões do pacote são atuais no 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 eu conheço é o ZoL, para o qual eu tenho (conforme fornecido pelo pacote zfsonlinux):

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

A execução hdparm -Rna unidade informa que o Write-Read-Verify está ativado (esse é um Seagate, também possui esse recurso e eu o uso como uma rede de segurança extra; a latência adicional de gravação não é um problema, pois meu padrão de uso interativo é muito lido -pesado):

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

Mesmo com a clara indicação de que algo está errado, zpool statusafirma que não há problema com a piscina:

  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 erro tem aparecido nos logs regularmente nos últimos dias (desde 27 de outubro), por isso não estou muito inclinado a considerá-lo meramente um acaso. Eu corro os discos com tempos limite SCTERC bastante curtos; 1,5 segundos de leitura (para recuperar rapidamente de erros de leitura), 10 segundos de gravação. Confirmei que esses valores estão ativos na unidade em questão.

O smartd continua me incomodando (o que por si só é uma coisa boa!) sobre o fato de a contagem de erros do ATA estar 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.

A execução smartctl --attributesna 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á. Observe que este é um drive corporativo, com garantia de cinco anos e classificado para operação 24 horas por dia, 7 dias por semana (o que significa que ele deve ser confiável por mais de 40.000 horas de operação, em comparação com as pouco menos de 10.000 horas disponíveis até o momento). Observe o número 5 no atributo 187 Reported_Uncorrect; é aí que está o problema. Observe também os valores bastante baixos de Start_Stop_Count e Power_Cycle_Count abaixo de 100 cada.

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

As propriedades não padrão do sistema de arquivos raiz no conjunto 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, para as perguntas:

1. Por que o ZFS não está relatando nada sobre o problema de leitura? Está claramente se recuperando disso.

2. Por que o ZFS não está reescrevendo automaticamente o setor de duff que a unidade está claramente tendo problemas para ler, por sua vez, provavelmente, acionando uma realocação pela unidade, considerando que existe redundância suficiente para reparo automático no caminho da solicitação de leitura?

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, no momento em que o driver do sistema de arquivos ZFS obtém 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 latência acima da média, portanto, nada é registrado.

O fato de o valor SMART de Reported_Uncorrect não ser 0 me faz suspeitar que a causa da falha é o próprio disco, em vez 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 na leitura, mesmo depois de muitas tentativas que o driver do dispositivo de bloco estiver tentando. Como tal, meu conselho seria substituir o disco.

O acionamento de um teste SMART longo provavelmente falhará nos blocos afetados, se você quiser que o erro desapareça, reescrevendo esses blocos (com dd por exemplo) deve fazer com que o disco troque esses setores, mas, na minha experiência, é quando a unidade é iniciada para ir, é melhor substituí-lo e acabar com ele.

Eu tinha um disco SCSI ruim com um ataque ZFS no Solaris. Eu estava varrendo os arquivos de log em busca de informações sobre mensagens de erro para reunir provas de que o disco estava com defeito e pedir à Oracle que o cubra na manutenção do hardware. Eu executei o grep para determinadas seqüências de caracteres nos logs de erros e essas linhas mostrando erros de disco estariam na tela do meu console. Quando o "Explorer" (a ferramenta de registro e geração de relatórios do Solaris) foi executado e enviado para a Oracle, eles disseram que não havia erros nos discos. Mas eu os tinha no histórico da tela. Eu verifiquei e foi realmente retirado dos logs no disco.

Aqui está o que estava acontecendo ... O ZFS promete zero erros no sistema de arquivos, não zero erros nos dados. Quando uma corrupção grave é encontrada, ela reverte a transação, fazendo o que for necessário para melhorar a integridade do sistema de arquivos. Como resultado, as atualizações de arquivo são perdidas quando ele volta para uma versão anterior do arquivo antes da corrupção e, portanto, pode ocorrer perda de dados. Mas 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 graves de mau comportamento do disco, pode entrar em um problema 22 onde os dados não estão sendo recuperados e gravados. Se você precisar coletar evidências de erros no disco, faça com que elas apareçam 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ções do ZFS.