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:
- 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.
- 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:
Por que o ZFS não está relatando nada sobre o problema de leitura? Está claramente se recuperando disso.
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?
fonte
Respostas:
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.
fonte
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.
fonte
zpool import -Fpoderá ser usado se os txgs recentes não puderem ser utilizados, mas reivindicações de reversões automáticas do txg exigiriam citações do IMO.